That's typically how we do things here at TinkerPop - we tend to allow "features that don't break public API" into the "z" of "x.y.z", however, we're trying to wind down development on the 3.1.x line of code and not introduce too much more there. I'd be open to a new bits of documentation on that line if it is applicable to 3.1.x, but I guess it would depend on what that documentation was. I think that if someone thinks something should go in 3.1.x at this point they can just do a DISCUSS thread here on dev and look to build some consensus.
I think that EOL of 3.1.x was what this email was about. We plan to continue to fix things there and maintain it for the foreseeable future. 3.2.x will also continue for the foreseeable future. Next body of releases haven't been discussed I don't think. I'm just throwing ideas out there, but I would think that 3.2.2 (and 3.1.4 i suppose if there's anything to release) would come as soon as gremlin-python is settled - maybe end of summer? Then 3.3.x (and 3.2.3/3.1.5???) by end of year? we seem to be in a general pattern of releasing something every couple of months or so, so i'm largely basing my thoughts on that at this point. On Tue, Jul 19, 2016 at 11:09 AM, Robert Dale <[email protected]> wrote: > Stephen, I noticed a couple of issues moved out of 3.1.4 for reason of > bug fixes only. Typically the semantic versioning is limited to > "public API". So I would argue that adding a service script (optional > usage at that) and a tutorial (documentation) would not affect the > public API or even general behavior of any of the components. Of > course, how you interpret and apply semantic versioning is entirely up > to you. > > Are there any plans or thoughts on a support roadmap (when 3.1, 3.2 > are EOL) and future release roadmap, timelines? > > > On Tue, Jul 19, 2016 at 10:49 AM, Stephen Mallette <[email protected]> > wrote: > > It sounds like we have general consensus on going with 3.1.x for bug > fixes > > only. I've updated JIRA as such and moved issues around. I will mention > > that while i was going through the release work for 3.1.3/3.2.1 I > realized > > that the minor exception to this rule of "bug fixes only" on the 3.1.x > line > > would be changes to the release process which I would hope we could keep > as > > similar as possible for as long as possible. I'd hate to have different > > scripts/instructions for one version as opposed to another - that will > not > > make the job of release manager nice. > > > > Thanks, > > > > Stephen > > > > > > On Mon, Jul 18, 2016 at 9:02 PM, Dylan Millikin < > [email protected]> > > wrote: > > > >> +1 from me as well. Sounds good. > >> > >> On Thu, Jul 14, 2016 at 2:14 PM, Ted Wilmes <[email protected]> wrote: > >> > >> > It does for me too, +1. > >> > > >> > --Ted > >> > > >> > On Wed, Jul 13, 2016 at 3:44 PM, Hadrian Zbarcea <[email protected]> > >> > wrote: > >> > > >> > > +1. It does to me. > >> > > Hadrian > >> > > > >> > > > >> > > On 07/13/2016 04:29 PM, Stephen Mallette wrote: > >> > > > >> > >> Since we don't really follow semantic versioning for releases, I > >> thought > >> > >> we > >> > >> should discuss the 3.1.x code line. We've been steadily adding > >> features > >> > >> right up to our current 3.1.3 release which we will vote on > shortly. I > >> > >> think it's pretty awesome that we've managed to maintain that older > >> line > >> > >> of > >> > >> code for as long as we have and I think we've evolved it in a very > >> > >> sensible > >> > >> way. > >> > >> > >> > >> I think we should continue to maintain 3.1.x after the 3.1.3 > release, > >> > >> which > >> > >> would mean a 3.1.4 release at some point, but we should strictly > limit > >> > the > >> > >> changes there to bug fixes and not do any "new features" on that > line > >> of > >> > >> code (i.e the tp31 branch). As it stands, I don't see any open > "bugs" > >> > for > >> > >> the 3.1.3 in JIRA so as of right now, we wouldn't have much planned > >> for > >> > >> 3.1.4. > >> > >> > >> > >> Does that make sense for everyone? > >> > >> > >> > >> > >> > > >> > > > > -- > Robert Dale >
