tinkerpop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Mallette <spmalle...@gmail.com>
Subject Re: 3.2.0 code freeze
Date Tue, 05 Apr 2016 16:05:02 GMT
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.millikin@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 <okrammarko@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 <spmallette@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.millikin@gmail.com>
> > > wrote:
> > >
> > >> Sounds good.
> > >>
> > >> On Mon, Apr 4, 2016 at 6:33 PM, Stephen Mallette <
> spmallette@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 <
> spmallette@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
> > >>>>
> > >>>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message