I'm about done with release stuff. No problems. Our docs for release are really stable now i think. They seem good enough at this point that anyone could pick it up and make a release happen. VOTE email will be out shortly. I'll bump back to SNAPSHOT in the respective branches, deploy initial docs, and otherwise get stuff ready for development again on Monday (or over the weekend if I'm feeling up to it).
On Fri, Apr 8, 2016 at 7:08 AM, Stephen Mallette <spmalle...@gmail.com> wrote: > 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 >>> > >>>> >>> > >>> >>> > >> >>> > >>> > >>> >> >> >
