Excellent. This makes sense to me. Thank you, Marko.
http://markorodriguez.com On Jul 14, 2015, at 5:05 AM, Stephen Mallette <[email protected]> wrote: > 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. >>>>> >>>> >>> >>
