On Wed, Apr 13, 2016 at 02:02:23PM -0400, Richard Heck wrote: > On 04/13/2016 05:20 AM, Pavel Sanda wrote: > > Scott Kostyshak wrote: > >> 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 would prefer to see 2.2.0 final commit in master, reason being > > history searches via git log etc. > > Then I propose to go ahead and create 2.3-staging and 2.2.1-staging now. > The former will be open for all commits, as if it were master, and will > eventually be merged to master; the latter will be treated as stable and > will be managed by me alongside 2.1.x. > > OK?
Yes I agree. This is simple and I think it will be easy for everyone to understand. In addition to what you said, it seems that master should be merged into 2.2.1-staging immediately after the 2.2.0 release (and of course before merging 2.3-staging to master) right? Do you have macros that accomplish this? If so, please go ahead. Otherwise, I believe the following commands would accomplish what we want: git checkout master git branch 2.3.staging git branch 2.2.1-staging git push -u origin 2.2.1-staging To discuss another issue, let's take the situation of a very safe commit that fixes a bug (so we want this in the 2.2.0 release). Which of the following do you (and others) have in mind? - commit separately (e.g. with cherry-pick) to 2.3-staging, 2.2.1-staging, and master - commit only to master, because after 2.2.0 is released 2.2.1-staging will also get this commit - commit only to master, but every week we merge master back into both 2.2.1-staging and 2.3-staging Scott
signature.asc
Description: PGP signature
