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
