I've created the tp30 branch starting at tags/3.0.0-incubating and set the version at 3.0.1-SNAPSHOT. "master" is at 3.1.0-SNAPSHOT. Note that I've also created versions 3.0.1-incubating and 3.1.0-incubating in jira.
On Mon, Jul 13, 2015 at 2:27 PM, Matt Frantz <[email protected]> wrote: > Makes sense to me. > > On Mon, Jul 13, 2015 at 11:03 AM, Stephen Mallette <[email protected]> > wrote: > > > Thanks for your thoughts Matt....I'm ok with that model as well. Under > > that model, we would create tp30 to maintain the 3.0.x line then commit > > everything else to master (which would be the 3.1.x line), merging back > to > > master from tp30 as needed. In suggesting the approach that I did, I > guess > > I sorta thought that the place "where most people are > > working" post-GA would be the 3.0.x line. I think we would be looking to > > avoid breaking change in the immediate term, so 3.0.x==master made sense > to > > me. > > > > > > > > On Mon, Jul 13, 2015 at 1:45 PM, Matt Frantz <[email protected] > > > > wrote: > > > > > +1 > > > > > > A roughly symmetric branching strategy would assign the master branch > to > > > the role of "where most people are working". Release branches, e.g. > > 3.0.0, > > > would be created when we "feature freeze" them. Bug fixes go there, > and > > > those release branches are periodically merged to master. When > > development > > > stops, those branches can be tagged and deleted. > > > > > > On Mon, Jul 13, 2015 at 4:20 AM, Stephen Mallette < > [email protected]> > > > wrote: > > > > > > > I think it's worthwhile for us to do something we've not really done > > > before > > > > with any of the TinkerPop projects: use branches. We typically tend > to > > > use > > > > branches for major refactoring that we might throw out, but not > really > > > for > > > > release management. As we look past release 3.0.0, I think we will > want > > > to > > > > have the capability to do more frequent minor releases (e.g. 3.0.1, > > > 3.0.2, > > > > etc) while still being able to do work for a future 3.1.x line of > code. > > > > > > > > I think we can do this without too much change if we introduce a > simple > > > > branch system. Release branch rules would be simple - we create a > new > > > > branch from master called tp31 for the 3.1.x line of code. Any > changes > > > > that are "breaking", introduce significant risk, a "major" feature, > > etc. > > > > would be committed there. All other changes, bug fixes, non-breaking > > > > refactoring of major APIs, "minor" features, etc. would simply commit > > to > > > > master. the master branch effectively becomes the 3.0.x line of > code. > > > > Under this approach the merge process is pretty simple in that we > just > > > > merge forward (i.e. master merges to to tp31). > > > > > > > > When the day comes that we're ready to release 3.1.0, we merge tp31 > > back > > > to > > > > master and create tp32 and use the same model where the 3.1.x line is > > > > master and the 3.2.x line is tp32. Of course, under this model we > are > > > > really supporting just the previous minor version, which for right > now > > > > seems acceptable to me. That's more than what we've ever really done > > > well, > > > > so that feels like a good starting point in my book. After we > release > > > > 3.1.0 we can revisit and decide if a more complex branching strategy > is > > > > needed. > > > > > > > > > >
