On Tue, Apr 12, 2016 at 09:52:47PM +0200, Jean-Marc Lasgouttes wrote: > Le 12/04/16 21:33, Scott Kostyshak a écrit : > >Let's focus on the following options: > > > >A) Branch 2.3.staging from master and continue "unstable" development on > >2.3.staging. After 2.2.0 is released we merge 2.3.staging into > >master. > > > >B) Branch 2.2.x from master and continue "unstable" development on > >master. > > > >To me it does not feel right that the commits in-between 2.2.0rc1 and > >2.2.0 final would not *necessarily* be in master's commit history. I > >think this breaks precedent. Although we would in practice cherry-pick > >from one to the other, this would not be true for the commits that are > >specific to the 2.2.0 release. Specifically, to me it feels right that > >fde16219 is in master's commit history. > > As a data point, gcc seems to do the early branching: > http://www.phoronix.com/scan.php?page=news_item&px=gcc-5-branched-gcc-6.0 > > If you look at Qt, they would have branched at the time of feature freeze > (with comparable delays): > https://wiki.qt.io/Qt_5.7_Release
Branching is one thing but merging after the release is another. I took a look at Qt (to be specific, the qtbase repository). I chose 5.5 release to look at. The 5.5.0 release (commit hash fae33bfb or tag "v5.5.0") is in the master history. Looking at the branching in gitk confirms that 5.5.0 branch was merged back into the 5.5 branch (which would be our equivalent of the master branch). As regards to LyX I don't care much whether we branch staging for branch release, but it does make sense to me that there is a merge afterwards. > >I don't see the advantage of B over A and I don't think we have done B > >before. > > This is why it is so exciting ;) > > >JMarc or anyone else would you have a strong opinion _against_ going > >with A over B? > > I do not have a strong opinion. Whatever you choose will be fine. OK. Scott
signature.asc
Description: PGP signature
