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;:

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

2015-02-26 18:47 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: 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> 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 > >

2015-02-26 19:27 GMT+01:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: 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.