You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2016/04/01 20:00:30 UTC
3.2.0 code freeze
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
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
I just bumped to 3.1.3-SNAPSHOT and 3.2.1-SNAPSHOT on tp31 and master
respectively. Initial snapshots have been deployed and docs are published.
Kuppitz, could you please start a new DISCUSS thread with the list of
"dead" branches that would be removed with your clean up script?
On Fri, Apr 8, 2016 at 4:00 PM, Stephen Mallette <sp...@gmail.com>
wrote:
> 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 <sp...@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 <sp...@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.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 <ok...@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 <sp...@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
>>>> > >>>>
>>>> > >>>
>>>> > >>
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
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 <sp...@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 <sp...@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.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 <ok...@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 <sp...@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
>>> > >>>>
>>> > >>>
>>> > >>
>>> >
>>> >
>>>
>>
>>
>
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
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 <sp...@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 <dy...@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 <ok...@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 <sp...@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
>> > >>>>
>> > >>>
>> > >>
>> >
>> >
>>
>
>
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
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 <dy...@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 <ok...@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 <sp...@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
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: 3.2.0 code freeze
Posted by Dylan Millikin <dy...@gmail.com>.
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 <ok...@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 <sp...@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 <sp...@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
> >>>>
> >>>
> >>
>
>
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
I just deployed the latest snapshots for 3.1.2 and 3.2.0.
On Tue, Apr 5, 2016 at 9:58 AM, Marko Rodriguez <ok...@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 <sp...@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 <sp...@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
> >>>>
> >>>
> >>
>
>
Re: 3.2.0 code freeze
Posted by Marko Rodriguez <ok...@gmail.com>.
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 <sp...@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 <dy...@gmail.com>
> wrote:
>
>> Sounds good.
>>
>> On Mon, Apr 4, 2016 at 6:33 PM, Stephen Mallette <sp...@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 <sp...@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
>>>>
>>>
>>
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
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 <dy...@gmail.com>
wrote:
> Sounds good.
>
> On Mon, Apr 4, 2016 at 6:33 PM, Stephen Mallette <sp...@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 <sp...@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
> > >
> >
>
Re: 3.2.0 code freeze
Posted by Dylan Millikin <dy...@gmail.com>.
Sounds good.
On Mon, Apr 4, 2016 at 6:33 PM, Stephen Mallette <sp...@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 <sp...@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
> >
>
Re: 3.2.0 code freeze
Posted by Stephen Mallette <sp...@gmail.com>.
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 <sp...@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
>