I like Dan's idea thought not sure if this would comply with git flow process or interpreting 'releases' more strictly.
Is it possible to have one git branch for the release version (1.0.0) but use tags for different 'stages' alpha1, alpha2, RC, etc? In my mind, alpha1, alpha2, beta, RC are part of the same 'release branch' if the feature scope is stable. My $0.02, Nitin ________________________________________ From: Mark Bretl <[email protected]> Sent: Wednesday, January 6, 2016 3:21 PM To: [email protected] Subject: Re: Ready for release candidate? 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 <[email protected]> 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 <[email protected]> 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 > > > > >
