I agree. We have been merging upstream so it's only natural that 3.1.2 be released before 3.2.0. I was a little confused about having 3.2.0 come out before so now it makes more sense.
If in the future we want to be able to do this we will need our workflow to merge downstream instead. Basically that would mean that all changes we want to make to 3.2.1 would be done against 3.3.0 then cherry picked and merged down to 3.2.1 (There's a subtle difference, if you fix a feature on 3.2.1 that no longer exists in 3.3.0 for example). As far as the changelogs go, you would add the changes to whichever version(s) they were merged/applied to even if it means having duplicates. The changes merged from 3.3.0 to 3.2.1 would be in the changelog for both version but 3.2.1 would have an extra mention like "backport" (which would most likely be the majority of changes). Honestly this is tedious and only worth it if we plan on providing extended support for minor versions, (do we want to? guess this would warrant it's own discussion anyways). On Tue, Apr 5, 2016 at 3:58 PM, Marko Rodriguez <okramma...@gmail.com> wrote: > Hi, > > I think we should release 3.1.2 as well. > > Marko. > > http://markorodriguez.com > > On Apr 5, 2016, at 7:56 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > > > I was reviewing the upgrade docs and release notes today and realized we > > have some weirdness because TinkerPop 3.2.0 is releasing prior to 3.1.2. > > 3.2.0 encompasses all of the changes in 3.1.2, so to find out what 3.2.0 > > has, you kinda have to look at both 3.1.2 and 3.2.0 upgrade docs. I'm > > starting to wonder if that will be confusing for folks who scroll down to > > 3.1.2 to see "Not Officially Released Yet". > > > > Marko had asked at one point if we were releasing 3.1.2 along with 3.2.0 > > and I'd indicated an answer of "no", but looking at it this way makes me > > wonder if that's the right call. It seems like the call to release a > > downstream version of TinkerPop should trigger the release of all > versions > > that it encompasses. So I guess the question is whether or not we should: > > > > 1. release 3.1.2 in conjunction with 3.2.0 (3.1.2 is as ready to go imo > as > > 3.2.0 at this point) > > 2. make it a TinkerPop policy to release all dependent versions of the > most > > recent expected release > > > > Of course, this does mean that we need to focus on testing BOTH 3.1.2 and > > 3.2.0 this week if we want to go this route so there's some added work > > there. Thoughts? > > > > On Mon, Apr 4, 2016 at 12:34 PM, Dylan Millikin < > dylan.milli...@gmail.com> > > wrote: > > > >> Sounds good. > >> > >> On Mon, Apr 4, 2016 at 6:33 PM, Stephen Mallette <spmalle...@gmail.com> > >> wrote: > >> > >>> I think we should basically freeze the whole repo at this point. I'd > said > >>> in the last post that tp31 branch was still open to dev, but that's > not a > >>> great idea as we might yet have tweaks for master that could occur in > >>> tp31. So, I think the better approach should be to assume that master > >> and > >>> tp31 are both frozen except for change that will go into 3.2.0's > release > >>> build this friday. > >>> > >>> On Fri, Apr 1, 2016 at 2:00 PM, Stephen Mallette <spmalle...@gmail.com > > > >>> wrote: > >>> > >>>> Code freeze is basically in effect starting tomorrow for our master > >>>> branch. Development on the tp31 branch can continue as needed, but, > of > >>>> course, do not merge tp31 back to master during our freeze. Please use > >>> this > >>>> week to run tests and report problems/findings. > >>>> > >>>> As usual it would be great to hear from driver/graph providers next > >> week > >>>> to see how their implementations are working against 3.2.0-SNAPSHOT (I > >>> will > >>>> publish a "final" SNAPSHOT later today for testing). > >>>> > >>>> I would have liked to have gotten this PR from Kuppitz merged before > >>>> freeze: > >>>> > >>>> https://github.com/apache/incubator-tinkerpop/pull/286 > >>>> > >>>> as that's a really good change, but it really isn't required for our > >>>> "release" - it's for our development productivity, so i don't think we > >>> need > >>>> to rush for that. > >>>> > >>>> Thanks, > >>>> > >>>> Stephen > >>>> > >>> > >> > >
