Re: [hibernate-dev] Branching strategy in OGM

2015-02-26 18:47 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > > On 26 February 2015 at 15:44, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > > 2015-02-26 16:38 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > >> > >> 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 ;)

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.

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(a)hibernate.org&gt; > >> 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(a)hibernate.org&gt;: > >> >> > >> >> 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(a)lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > >> > > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > >