[hibernate-dev] Branching strategy in OGM

[Gunnar Morling]

2015-02-26 19:27 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:

> On 26 February 2015 at 18:11, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2015-02-26 18:47 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> On 26 February 2015 at 15:44, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >> > 2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >>
> >> >> So you intend to do some evil history rewriting on branch 4.2? I
> don't
> >> >> think that's expected to happen on the reference repository.
> >> >
> >> >
> >> > I don't see a problem with rewriting in this case. It's not master and
> >> > it's
> >> > not there for a long time. It's just a temp. working branch.
> >> >
> >> >> I haven't understood much of it so I'll send PRs to master and let
> you
> >> >> merge them wherever you want. Pretty sure I don't want to touch
> branch
> >> >> 4.2 myself.
> >> >
> >> >
> >> > Best is to send PRs to that branch you want them applied to: 4.1.2 ->
> >> > master, 4.2 -> 4.2. I'll rebase your OGM-747 branch and merge to 4.2.
> >>
> >> That's not going to work. I just had a minor PR based on 4.2, but it
> >> seems you rewrote 4.2 in the meantime, I had to nuke my branch and
> >> rebuild it from ashes ;)
> >
> >
> > Ok, if you consider rebase --onto as rebuilding from ashes ;)
>
> It doesn't matter what exactly you do, what matters is that my clone
> is inconsistent and I have no clue of what could have happened.
>
>
> > Note that this branch basically was meant for Davide and me. Aren't you
> > supposed to work on 4.1.2 anyways ;) ? I would say let's do the 4.1.2
> > release tomorrow and if we then come to decide we need another 4.1.x
> > release, let's do what you suggest if it really is such a big problem.
>
> Thanks :)
> But I didn't say it's a big problem. It's unexpected though, and I
> think we had agreed that nobody would ever use push --force on the
> reference repository, especially not as a standard development
> procedure.
>

Sorry, I had discussed it with Davide whom I expected the only one to be
besides me to work on 4.2 at this point. Probably should have send a quick
mail to all.

What you say makes totally sense for master, I don't think the strict rule
needs to be applied for a short living working branch. I still think it's
good as it makes handling on 4.1.x easier for you guys (and those merging
all the PRs), but as said we can change it after 4.1.2 if you prefer.


> >
> > But we'll need two PRs for each 4.1.x change then. I didn't expect much
> > (integrated) traffic on 4.2 in this week so I liked the current approach
> to
> > keep the history nicer and avoiding merge/port PRs.
> >
> >> So you're the only one in control of this 4.2 branch I guess?
> >
> >
> > No, not necessarily. You can rebase it after something has been
> integrated
> > in 4.1.2 or we leave it as is and do just one final rebase after 4.1.2
> has
> > been released. Just be sure to have the current 4.2 prior to sending a PR
> > against it.
> >>
> >>
> >> >
> >> >> On 26 February 2015 at 15:26, Gunnar Morling <gunnar at hibernate.org>
> >> >> wrote:
> >> >> > We did it intentionally that way to avoid any kind of back/forward
> >> >> > porting
> >> >> > and keep the history linear.
> >> >> >
> >> >> > It's not that these branches are there for a long time, probably
> only
> >> >> > until
> >> >> > tomorrow. 4.2 is meant to be rebased onto master and finally
> >> >> > fast-forward
> >> >> > merged to master once 4.1.2 is out. Would be something different if
> >> >> > there
> >> >> > was a long-lasting 4.1 branch which needs parallel maintenance,
> then
> >> >> > I'd
> >> >> > do
> >> >> > what you suggest.
> >> >> >
> >> >> > --Gunnar
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2015-02-26 15:16 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> >> >>
> >> >> >> Hey all,
> >> >> >> it seems like the branch for maintenance work on OGM 4.1 is
> (still)
> >> >> >> called "master", while a branch "4.2" was created for future work.
> >> >> >>
> >> >> >> I'd really prefer it the other way around: create a branch "4.1"
> to
> >> >> >> host all changes which are needed to be backported on 4.1.x , and
> >> >> >> call
> >> >> >> "master" what will receive all of the latest improvements.
> >> >> >>
> >> >> >> Let's see on IRC when it is a good time to rename the branches? It
> >> >> >> better happens "atomically" or it's a mess..
> >> >> >>
> >> >> >> Sanne
> >> >> >> _______________________________________________
> >> >> >> hibernate-dev mailing list
> >> >> >> hibernate-dev at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >> >
> >> >> >
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>