On Tue, Apr 12, 2016 at 10:38:02PM +0200, Vincent van Ravesteijn wrote: > Op 12 apr. 2016 22:07 schreef "Vincent van Ravesteijn" <v...@lyx.org>: > > > > > > Op 12 apr. 2016 21:29 schreef "Jean-Marc Lasgouttes" <lasgout...@lyx.org>: > > > > > > > > Le 12/04/16 18:45, Scott Kostyshak a écrit : > > > > > >> So in the commit history of master we will not see the final 2.2.0 > > >> release (e.g. fde16219 for 2.1.0)? > > >> > > >> Have we done this before in this way? > > > > > > > > > No Vincent did not want that. But since he is away, we can be naughty. > > > > Hmm, maybe I just didn't want or was not allowed to break with history too > much. > > In my opinion, release management and branches should be done as follows: > > - all development for 2.3.0 can be done at master. > - all development for 2.2.0 can be done at a 2.2.x branch > > - do the release for 2.2.0Rc1 at a "release" branch based on the 2.2.x > branch at that moment (no need of closing/reopening branch anymore). This > means that the commits for 2.2.0rc1 that shouldn't be part of 2.3.0 do not > have to be reverted afterwards. E.g. this avoids changing version from dev > to Rc1 and back in the next commit. > > - Continue development and periodically merge the 2.2.x branch into master > (besides weird exceptions, all commits that go into 2.2.0 will be in the > master that will be the start of 2.3.0) > > - when Rc2 is to be released, merge 2.2.x into "release", change Rc1 to Rc2 > and tag. > > - Continue until 2.2.0 is released. > > Afterwards I would try to avoid cherry-picking as well as I hate the double > commit policy. However, the 2.2.x will be a dead branch eventually, so to > avoid git management we could continue like we always did. > > Conclusion: development can continue on master and still all commits that > form 2.2.0 are in the "new" master for 2.3.0, (except for the > version-change-like commits that are decoration). > > Vincent
Thanks for this detailed outline, Vincent. I read it and it makes sense to me (except for a couple of small questions that I would want to clarify to make sure I understand), but I think there is a larger chance that I would mess something up. Further, since we did not start doing this for rc1, and it's not clear to me whether we have done this in the past for LyX, I'm hesitant to start doing it now. I prefer to go with something that is simple for me to implement and easy for everyone else (even those with an aversion to git) to understand. Scott
signature.asc
Description: PGP signature
