We've had a few minor patches this week to fix a few things discovered during testing and It doesn't seem as though we've had any objections to 3.1.2/3.2.0 release so we will move forward with the dual release. I'm sure "dual release" will make my day interesting for reasons that will soon be revealed to me. Anyway - getting started on this now.
On Tue, Apr 5, 2016 at 12:05 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > I'd rather not think too hard about 3.3.x any time soon :) but, yes, we'd > have to take care with the workflow. At this time, I don't think we should > worry too heavily about maintaining more than two lines of releases at a > time which is what we've been doing thus far with 3.1.x (tp31) and 3.2.x > (master). I think we should continue with that pattern for a while where > after this release we do 3.1.3 on tp31 and 3.2.1 on master taking care to > focus on non-breaking change for both release branches. Then the merge flow > stays the same as what we've been doing. If there are more opinions about > this, please start a fresh DISCUSS thread and reference this thread so we > can keep this current thread more focused on code freeze/release issues. > > On Tue, Apr 5, 2016 at 11:30 AM, Dylan Millikin <dylan.milli...@gmail.com> > wrote: > >> 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 >> > >>>> >> > >>> >> > >> >> > >> > >> > >
