My thought is that the release branch should be short-lived (in this case hopefully < 2 weeks). I think it should match the version (which would be 1.0.0-incubating-alpha1). Then we can have subsequent release branches for 1.0.0-incubating-alpha2, etc.
I would say that even though alpha1, alpha2, … are stepping stones on the way to a 1.0.0 release it would be good to follow a consistent process. Anthony > On Jan 6, 2016, at 3:21 PM, Mark Bretl <asf.mbr...@gmail.com> wrote: > > I believe we are farther away from the actual '1.0.0' release, so it does > not make sense to have the long standing release branch. Since > '1.0.0-ALPHA' is the release name, I would expect the branch name to match. > This goes for any 'beta', M1, M2, Mx, then final '1.0.0' release branch. > > Those are my thoughts anyway... > > --Mark > > On Wed, Jan 6, 2016 at 3:10 PM, Dan Smith <dsm...@pivotal.io> wrote: > >> One question on the name of the release branch. Shouldn't we be calling it >> release/1.0.0-incubating and just tag alpha versions off of that branch? >> Why have multiple branches for the same release? >> >> -Dan >> >> On Wed, Jan 6, 2016 at 2:58 PM, Anthony Baker <aba...@pivotal.io> wrote: >> >>> I suggest that we’re pretty much ready to begin creating the alpha1 >>> release. I think the first step in the process is to create a release >>> branch (release/1.0.0-incubating-alpha1) and publish it. From there we >> can >>> finalize any further changes needed (like updates for GEODE-610, >>> gradle.properties version, etc). This will allow development to proceed >> on >>> the /develop branch without impacting the release. >>> >>> Thoughts? >>> >>> Anthony >>> >>> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
