Re: code freeze 3.2.10/3.3.4
tp32 is now open for business - snapshots/docs are deployed.
On Fri, Oct 26, 2018 at 8:18 AM Stephen Mallette
wrote:
> I'm +0 on formalizing too muchsome common sense like "release next
> cycle unless someone can provide a proof of concept or just feels strongly
> otherwise" is fine by me.
>
> > If you're going to reopen tp32, then I'll retarget
>
> sounds good - thanks for staying up on the "security" stuff
>
> On Fri, Oct 26, 2018 at 8:06 AM Robert Dale wrote:
>
>> If you're going to reopen tp32, then I'll retarget
>> https://github.com/apache/tinkerpop/pull/969
>>
>> Robert Dale
>>
>>
>> On Fri, Oct 26, 2018 at 7:56 AM Robert Dale wrote:
>>
>> > So to answer your earlier question on security fixes, the driver should
>> be
>> > our security policy ;-)
>> >
>> > For example, if tp32 is not officially closed and accepts bug fixes, and
>> > given "security problems are just bugs" [1], then tp32 should get
>> > security-related bug fixes.
>> >
>> > We can use CVSS [2] to score vulnerabilities. They even have a
>> handy-dandy
>> > calculator [3].
>> >
>> > The release trigger should also be in the security policy. It could be
>> > based on the CVSS score:
>> > <5, next scheduled release
>> > <7, within 30 days
>> > <8, within 2 weeks
>> > <9, within 1 week
>> > 9+, asap
>> >
>> > Or we just keep it simple, release next cycle unless someone can
>> provide a
>> > proof of concept or just feels strongly otherwise.
>> >
>> > For example, I don't think TINKERPOP-2068 [4] is critical because our
>> > serializers handle only explicitly listed types. Nothing is blindly
>> > delegated to Jackson. No need for an emergency release. Someone can
>> confirm.
>> >
>> > 1. https://lkml.org/lkml/2017/11/17/767
>> > 2. https://www.first.org/cvss/
>> > 3. https://www.first.org/cvss/calculator/3.0
>> > 4. https://issues.apache.org/jira/browse/TINKERPOP-2068
>> >
>> > Robert Dale
>> >
>> >
>> > On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
>> > wrote:
>> >
>> >> tp32...
>> >>
>> >> i started thinking that we could keep a JIRA ticket open that had a
>> list
>> >> of
>> >> bugs we might backport to tp32 should we have some triggering event,
>> >> buti dunno. maybe we go with a first step at this and re-open the
>> >> branch but just ship security+bug fixes at it and not try to wait for a
>> >> triggering event for release. i would expect the CHANGELOG for 3.2.11
>> to
>> >> be
>> >> really small if we do this right. please let me know if there are any
>> >> concerns, otherwise we'll start heading down this route and i'll
>> re-open
>> >> the branch on Monday.
>> >>
>> >> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette <
>> spmalle...@gmail.com>
>> >> wrote:
>> >>
>> >> > there's always going to be those kinds of things though right? can we
>> >> get
>> >> > away with doing stuff to tp32 only when there is some specific demand
>> >> for a
>> >> > 3.2.11. like, that fix on its own doesn't feel like something we'd
>> >> trigger
>> >> > a release overor would we?
>> >> >
>> >> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale
>> wrote:
>> >> >
>> >> >> You don't want to put
>> >> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
>> >> >> on tp32?
>> >> >>
>> >> >> Robert Dale
>> >> >>
>> >> >>
>> >> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette <
>> spmalle...@gmail.com
>> >> >
>> >> >> wrote:
>> >> >>
>> >> >> > > I created a ticket to track this and I can probably take care
>> of
>> >> it
>> >> >> next
>> >> >> > week
>> >> >> >
>> >> >> > that makes sense, thank you.
>> >> >> >
>> >> >> > separately, code freeze is now lifted on tp33 - i've bumped to
>> >> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good
>> to
>> >> go.
>> >> >> > I've left tp32 on 3.2.10 until we decide to actually do something
>> on
>> >> >> that
>> >> >> > branch. For now, we'll just say we're done there as we discussed
>> >> >> > elsethread.
>> >> >> >
>> >> >> > kuppitz, feel free to fire up the dead branch cleanup email. i
>> wonder
>> >> >> if it
>> >> >> > will be more convenient to delete branches as we go now that we
>> have
>> >> the
>> >> >> > github UI available to us. might be good to just hit the "delete
>> >> branch"
>> >> >> > button right when we hit the merge one.
>> >> >> >
>> >> >> > i will announce the releases on monday morning EST time.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
>> >> >> f...@florian-hockmann.de>
>> >> >> > wrote:
>> >> >> >
>> >> >> > > We currently use this to push the package:
>> >> >> > >
>> >> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
>> >> >> > >
>> >> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
>> >> >> probably
>> >> >> > > also had the package for version 3.4.0-rc2 in that directory.
>> So,
>> >> >> > > nuget.exe tried to push that version again which isn't allowed
>> by
>> >> >> NuGet
>> >> >> > > as packages are immutable for a given version.
>> >> >> > >
Re: code freeze 3.2.10/3.3.4
I'm +0 on formalizing too muchsome common sense like "release next
cycle unless someone can provide a proof of concept or just feels strongly
otherwise" is fine by me.
> If you're going to reopen tp32, then I'll retarget
sounds good - thanks for staying up on the "security" stuff
On Fri, Oct 26, 2018 at 8:06 AM Robert Dale wrote:
> If you're going to reopen tp32, then I'll retarget
> https://github.com/apache/tinkerpop/pull/969
>
> Robert Dale
>
>
> On Fri, Oct 26, 2018 at 7:56 AM Robert Dale wrote:
>
> > So to answer your earlier question on security fixes, the driver should
> be
> > our security policy ;-)
> >
> > For example, if tp32 is not officially closed and accepts bug fixes, and
> > given "security problems are just bugs" [1], then tp32 should get
> > security-related bug fixes.
> >
> > We can use CVSS [2] to score vulnerabilities. They even have a
> handy-dandy
> > calculator [3].
> >
> > The release trigger should also be in the security policy. It could be
> > based on the CVSS score:
> > <5, next scheduled release
> > <7, within 30 days
> > <8, within 2 weeks
> > <9, within 1 week
> > 9+, asap
> >
> > Or we just keep it simple, release next cycle unless someone can provide
> a
> > proof of concept or just feels strongly otherwise.
> >
> > For example, I don't think TINKERPOP-2068 [4] is critical because our
> > serializers handle only explicitly listed types. Nothing is blindly
> > delegated to Jackson. No need for an emergency release. Someone can
> confirm.
> >
> > 1. https://lkml.org/lkml/2017/11/17/767
> > 2. https://www.first.org/cvss/
> > 3. https://www.first.org/cvss/calculator/3.0
> > 4. https://issues.apache.org/jira/browse/TINKERPOP-2068
> >
> > Robert Dale
> >
> >
> > On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
> > wrote:
> >
> >> tp32...
> >>
> >> i started thinking that we could keep a JIRA ticket open that had a list
> >> of
> >> bugs we might backport to tp32 should we have some triggering event,
> >> buti dunno. maybe we go with a first step at this and re-open the
> >> branch but just ship security+bug fixes at it and not try to wait for a
> >> triggering event for release. i would expect the CHANGELOG for 3.2.11 to
> >> be
> >> really small if we do this right. please let me know if there are any
> >> concerns, otherwise we'll start heading down this route and i'll re-open
> >> the branch on Monday.
> >>
> >> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette >
> >> wrote:
> >>
> >> > there's always going to be those kinds of things though right? can we
> >> get
> >> > away with doing stuff to tp32 only when there is some specific demand
> >> for a
> >> > 3.2.11. like, that fix on its own doesn't feel like something we'd
> >> trigger
> >> > a release overor would we?
> >> >
> >> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale
> wrote:
> >> >
> >> >> You don't want to put
> >> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
> >> >> on tp32?
> >> >>
> >> >> Robert Dale
> >> >>
> >> >>
> >> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette <
> spmalle...@gmail.com
> >> >
> >> >> wrote:
> >> >>
> >> >> > > I created a ticket to track this and I can probably take care of
> >> it
> >> >> next
> >> >> > week
> >> >> >
> >> >> > that makes sense, thank you.
> >> >> >
> >> >> > separately, code freeze is now lifted on tp33 - i've bumped to
> >> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to
> >> go.
> >> >> > I've left tp32 on 3.2.10 until we decide to actually do something
> on
> >> >> that
> >> >> > branch. For now, we'll just say we're done there as we discussed
> >> >> > elsethread.
> >> >> >
> >> >> > kuppitz, feel free to fire up the dead branch cleanup email. i
> wonder
> >> >> if it
> >> >> > will be more convenient to delete branches as we go now that we
> have
> >> the
> >> >> > github UI available to us. might be good to just hit the "delete
> >> branch"
> >> >> > button right when we hit the merge one.
> >> >> >
> >> >> > i will announce the releases on monday morning EST time.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
> >> >> f...@florian-hockmann.de>
> >> >> > wrote:
> >> >> >
> >> >> > > We currently use this to push the package:
> >> >> > >
> >> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
> >> >> > >
> >> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
> >> >> probably
> >> >> > > also had the package for version 3.4.0-rc2 in that directory. So,
> >> >> > > nuget.exe tried to push that version again which isn't allowed by
> >> >> NuGet
> >> >> > > as packages are immutable for a given version.
> >> >> > >
> >> >> > > I guess we should specify the exact version here instead to avoid
> >> >> these
> >> >> > > problems in the future. Otherwise we could push development
> >> versions
> >> >> to
> >> >> > > nuget.org by accident. I probably implemented it like this at
> >> first
> >> >> > > because I assumed that mvn
Re: code freeze 3.2.10/3.3.4
If you're going to reopen tp32, then I'll retarget
https://github.com/apache/tinkerpop/pull/969
Robert Dale
On Fri, Oct 26, 2018 at 7:56 AM Robert Dale wrote:
> So to answer your earlier question on security fixes, the driver should be
> our security policy ;-)
>
> For example, if tp32 is not officially closed and accepts bug fixes, and
> given "security problems are just bugs" [1], then tp32 should get
> security-related bug fixes.
>
> We can use CVSS [2] to score vulnerabilities. They even have a handy-dandy
> calculator [3].
>
> The release trigger should also be in the security policy. It could be
> based on the CVSS score:
> <5, next scheduled release
> <7, within 30 days
> <8, within 2 weeks
> <9, within 1 week
> 9+, asap
>
> Or we just keep it simple, release next cycle unless someone can provide a
> proof of concept or just feels strongly otherwise.
>
> For example, I don't think TINKERPOP-2068 [4] is critical because our
> serializers handle only explicitly listed types. Nothing is blindly
> delegated to Jackson. No need for an emergency release. Someone can confirm.
>
> 1. https://lkml.org/lkml/2017/11/17/767
> 2. https://www.first.org/cvss/
> 3. https://www.first.org/cvss/calculator/3.0
> 4. https://issues.apache.org/jira/browse/TINKERPOP-2068
>
> Robert Dale
>
>
> On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
> wrote:
>
>> tp32...
>>
>> i started thinking that we could keep a JIRA ticket open that had a list
>> of
>> bugs we might backport to tp32 should we have some triggering event,
>> buti dunno. maybe we go with a first step at this and re-open the
>> branch but just ship security+bug fixes at it and not try to wait for a
>> triggering event for release. i would expect the CHANGELOG for 3.2.11 to
>> be
>> really small if we do this right. please let me know if there are any
>> concerns, otherwise we'll start heading down this route and i'll re-open
>> the branch on Monday.
>>
>> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette
>> wrote:
>>
>> > there's always going to be those kinds of things though right? can we
>> get
>> > away with doing stuff to tp32 only when there is some specific demand
>> for a
>> > 3.2.11. like, that fix on its own doesn't feel like something we'd
>> trigger
>> > a release overor would we?
>> >
>> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
>> >
>> >> You don't want to put
>> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
>> >> on tp32?
>> >>
>> >> Robert Dale
>> >>
>> >>
>> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette > >
>> >> wrote:
>> >>
>> >> > > I created a ticket to track this and I can probably take care of
>> it
>> >> next
>> >> > week
>> >> >
>> >> > that makes sense, thank you.
>> >> >
>> >> > separately, code freeze is now lifted on tp33 - i've bumped to
>> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to
>> go.
>> >> > I've left tp32 on 3.2.10 until we decide to actually do something on
>> >> that
>> >> > branch. For now, we'll just say we're done there as we discussed
>> >> > elsethread.
>> >> >
>> >> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder
>> >> if it
>> >> > will be more convenient to delete branches as we go now that we have
>> the
>> >> > github UI available to us. might be good to just hit the "delete
>> branch"
>> >> > button right when we hit the merge one.
>> >> >
>> >> > i will announce the releases on monday morning EST time.
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
>> >> f...@florian-hockmann.de>
>> >> > wrote:
>> >> >
>> >> > > We currently use this to push the package:
>> >> > >
>> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
>> >> > >
>> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
>> >> probably
>> >> > > also had the package for version 3.4.0-rc2 in that directory. So,
>> >> > > nuget.exe tried to push that version again which isn't allowed by
>> >> NuGet
>> >> > > as packages are immutable for a given version.
>> >> > >
>> >> > > I guess we should specify the exact version here instead to avoid
>> >> these
>> >> > > problems in the future. Otherwise we could push development
>> versions
>> >> to
>> >> > > nuget.org by accident. I probably implemented it like this at
>> first
>> >> > > because I assumed that mvn clean would always remove older packages
>> >> > > which seems to be not the case here.
>> >> > >
>> >> > > Anyway, I created a ticket to track this and I can probably take
>> care
>> >> of
>> >> > > it next week:
>> >> > >
>> >> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
>> >> > >
>> >> > >
>> >> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
>> >> > > > Florian, any idea what's going on with this error when i deployed
>> >> > 3.3.4:
>> >> > > >
>> >> > > > main:
>> >> > > > [echo] nuget.exe already downloaded.
>> >> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
>> >> > > > https://www.nuget.org/api/v
Re: code freeze 3.2.10/3.3.4
So to answer your earlier question on security fixes, the driver should be
our security policy ;-)
For example, if tp32 is not officially closed and accepts bug fixes, and
given "security problems are just bugs" [1], then tp32 should get
security-related bug fixes.
We can use CVSS [2] to score vulnerabilities. They even have a handy-dandy
calculator [3].
The release trigger should also be in the security policy. It could be
based on the CVSS score:
<5, next scheduled release
<7, within 30 days
<8, within 2 weeks
<9, within 1 week
9+, asap
Or we just keep it simple, release next cycle unless someone can provide a
proof of concept or just feels strongly otherwise.
For example, I don't think TINKERPOP-2068 [4] is critical because our
serializers handle only explicitly listed types. Nothing is blindly
delegated to Jackson. No need for an emergency release. Someone can confirm.
1. https://lkml.org/lkml/2017/11/17/767
2. https://www.first.org/cvss/
3. https://www.first.org/cvss/calculator/3.0
4. https://issues.apache.org/jira/browse/TINKERPOP-2068
Robert Dale
On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
wrote:
> tp32...
>
> i started thinking that we could keep a JIRA ticket open that had a list of
> bugs we might backport to tp32 should we have some triggering event,
> buti dunno. maybe we go with a first step at this and re-open the
> branch but just ship security+bug fixes at it and not try to wait for a
> triggering event for release. i would expect the CHANGELOG for 3.2.11 to be
> really small if we do this right. please let me know if there are any
> concerns, otherwise we'll start heading down this route and i'll re-open
> the branch on Monday.
>
> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette
> wrote:
>
> > there's always going to be those kinds of things though right? can we get
> > away with doing stuff to tp32 only when there is some specific demand
> for a
> > 3.2.11. like, that fix on its own doesn't feel like something we'd
> trigger
> > a release overor would we?
> >
> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
> >
> >> You don't want to put
> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
> >> on tp32?
> >>
> >> Robert Dale
> >>
> >>
> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette
> >> wrote:
> >>
> >> > > I created a ticket to track this and I can probably take care of it
> >> next
> >> > week
> >> >
> >> > that makes sense, thank you.
> >> >
> >> > separately, code freeze is now lifted on tp33 - i've bumped to
> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to
> go.
> >> > I've left tp32 on 3.2.10 until we decide to actually do something on
> >> that
> >> > branch. For now, we'll just say we're done there as we discussed
> >> > elsethread.
> >> >
> >> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder
> >> if it
> >> > will be more convenient to delete branches as we go now that we have
> the
> >> > github UI available to us. might be good to just hit the "delete
> branch"
> >> > button right when we hit the merge one.
> >> >
> >> > i will announce the releases on monday morning EST time.
> >> >
> >> >
> >> >
> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
> >> f...@florian-hockmann.de>
> >> > wrote:
> >> >
> >> > > We currently use this to push the package:
> >> > >
> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
> >> > >
> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
> >> probably
> >> > > also had the package for version 3.4.0-rc2 in that directory. So,
> >> > > nuget.exe tried to push that version again which isn't allowed by
> >> NuGet
> >> > > as packages are immutable for a given version.
> >> > >
> >> > > I guess we should specify the exact version here instead to avoid
> >> these
> >> > > problems in the future. Otherwise we could push development versions
> >> to
> >> > > nuget.org by accident. I probably implemented it like this at first
> >> > > because I assumed that mvn clean would always remove older packages
> >> > > which seems to be not the case here.
> >> > >
> >> > > Anyway, I created a ticket to track this and I can probably take
> care
> >> of
> >> > > it next week:
> >> > >
> >> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
> >> > >
> >> > >
> >> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
> >> > > > Florian, any idea what's going on with this error when i deployed
> >> > 3.3.4:
> >> > > >
> >> > > > main:
> >> > > > [echo] nuget.exe already downloaded.
> >> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
> >> > > > https://www.nuget.org/api/v2/package'...
> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/
> >> > > > [exec] Created https://www.nuget.org/api/v2/package/
> 1362ms
> >> > > > [exec] Your package was pushed.
> >> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
> >> > > > https://www.nuget.org/api/v2/package'...
> >> > > >
Re: code freeze 3.2.10/3.3.4
tp32...
i started thinking that we could keep a JIRA ticket open that had a list of
bugs we might backport to tp32 should we have some triggering event,
buti dunno. maybe we go with a first step at this and re-open the
branch but just ship security+bug fixes at it and not try to wait for a
triggering event for release. i would expect the CHANGELOG for 3.2.11 to be
really small if we do this right. please let me know if there are any
concerns, otherwise we'll start heading down this route and i'll re-open
the branch on Monday.
On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette
wrote:
> there's always going to be those kinds of things though right? can we get
> away with doing stuff to tp32 only when there is some specific demand for a
> 3.2.11. like, that fix on its own doesn't feel like something we'd trigger
> a release overor would we?
>
> On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
>
>> You don't want to put
>> https://issues.apache.org/jira/browse/TINKERPOP-2068
>> on tp32?
>>
>> Robert Dale
>>
>>
>> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette
>> wrote:
>>
>> > > I created a ticket to track this and I can probably take care of it
>> next
>> > week
>> >
>> > that makes sense, thank you.
>> >
>> > separately, code freeze is now lifted on tp33 - i've bumped to
>> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to go.
>> > I've left tp32 on 3.2.10 until we decide to actually do something on
>> that
>> > branch. For now, we'll just say we're done there as we discussed
>> > elsethread.
>> >
>> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder
>> if it
>> > will be more convenient to delete branches as we go now that we have the
>> > github UI available to us. might be good to just hit the "delete branch"
>> > button right when we hit the merge one.
>> >
>> > i will announce the releases on monday morning EST time.
>> >
>> >
>> >
>> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
>> f...@florian-hockmann.de>
>> > wrote:
>> >
>> > > We currently use this to push the package:
>> > >
>> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
>> > >
>> > > which pushes all NuGet packages starting with Gremlin.Net. You
>> probably
>> > > also had the package for version 3.4.0-rc2 in that directory. So,
>> > > nuget.exe tried to push that version again which isn't allowed by
>> NuGet
>> > > as packages are immutable for a given version.
>> > >
>> > > I guess we should specify the exact version here instead to avoid
>> these
>> > > problems in the future. Otherwise we could push development versions
>> to
>> > > nuget.org by accident. I probably implemented it like this at first
>> > > because I assumed that mvn clean would always remove older packages
>> > > which seems to be not the case here.
>> > >
>> > > Anyway, I created a ticket to track this and I can probably take care
>> of
>> > > it next week:
>> > >
>> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
>> > >
>> > >
>> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
>> > > > Florian, any idea what's going on with this error when i deployed
>> > 3.3.4:
>> > > >
>> > > > main:
>> > > > [echo] nuget.exe already downloaded.
>> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
>> > > > https://www.nuget.org/api/v2/package'...
>> > > > [exec] PUT https://www.nuget.org/api/v2/package/
>> > > > [exec] Created https://www.nuget.org/api/v2/package/ 1362ms
>> > > > [exec] Your package was pushed.
>> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
>> > > > https://www.nuget.org/api/v2/package'...
>> > > > [exec] PUT https://www.nuget.org/api/v2/package/
>> > > > [exec] Created https://www.nuget.org/api/v2/package/ 11405ms
>> > > > [exec] Your package was pushed.
>> > > > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
>> > > > https://www.nuget.org/api/v2/package'...
>> > > > [exec] PUT https://www.nuget.org/api/v2/package/
>> > > > [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms
>> > > > [exec] 409 (A package with ID 'Gremlin.Net.Template' and
>> version
>> > > > '3.4.0-rc2' already exists and cannot be modified.)
>> > > >
>> > > >
>> > > > why is it trying to push the 3.4.0 line? looks like the error
>> didn't
>> > > > matter as the other two published fine, but let's fix the error if
>> we
>> > > > can...
>> > > >
>> > > > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette <
>> spmalle...@gmail.com
>> > >
>> > > > wrote:
>> > > >
>> > > >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT
>> artifacts
>> > > and
>> > > >> docs too:
>> > > >>
>> > > >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette <
>> > spmalle...@gmail.com>
>> > > >> wrote:
>> > > >>
>> > > >>> I just published final 3.3.4-SNAPSHOT artifacts and docs:
>> > > >>>
>> > > >>> http://tinke
Re: code freeze 3.2.10/3.3.4
there's always going to be those kinds of things though right? can we get
away with doing stuff to tp32 only when there is some specific demand for a
3.2.11. like, that fix on its own doesn't feel like something we'd trigger
a release overor would we?
On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
> You don't want to put https://issues.apache.org/jira/browse/TINKERPOP-2068
> on tp32?
>
> Robert Dale
>
>
> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette
> wrote:
>
> > > I created a ticket to track this and I can probably take care of it
> next
> > week
> >
> > that makes sense, thank you.
> >
> > separately, code freeze is now lifted on tp33 - i've bumped to
> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to go.
> > I've left tp32 on 3.2.10 until we decide to actually do something on that
> > branch. For now, we'll just say we're done there as we discussed
> > elsethread.
> >
> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder if
> it
> > will be more convenient to delete branches as we go now that we have the
> > github UI available to us. might be good to just hit the "delete branch"
> > button right when we hit the merge one.
> >
> > i will announce the releases on monday morning EST time.
> >
> >
> >
> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann >
> > wrote:
> >
> > > We currently use this to push the package:
> > >
> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
> > >
> > > which pushes all NuGet packages starting with Gremlin.Net. You probably
> > > also had the package for version 3.4.0-rc2 in that directory. So,
> > > nuget.exe tried to push that version again which isn't allowed by NuGet
> > > as packages are immutable for a given version.
> > >
> > > I guess we should specify the exact version here instead to avoid these
> > > problems in the future. Otherwise we could push development versions to
> > > nuget.org by accident. I probably implemented it like this at first
> > > because I assumed that mvn clean would always remove older packages
> > > which seems to be not the case here.
> > >
> > > Anyway, I created a ticket to track this and I can probably take care
> of
> > > it next week:
> > >
> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
> > >
> > >
> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
> > > > Florian, any idea what's going on with this error when i deployed
> > 3.3.4:
> > > >
> > > > main:
> > > > [echo] nuget.exe already downloaded.
> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
> > > > https://www.nuget.org/api/v2/package'...
> > > > [exec] PUT https://www.nuget.org/api/v2/package/
> > > > [exec] Created https://www.nuget.org/api/v2/package/ 1362ms
> > > > [exec] Your package was pushed.
> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
> > > > https://www.nuget.org/api/v2/package'...
> > > > [exec] PUT https://www.nuget.org/api/v2/package/
> > > > [exec] Created https://www.nuget.org/api/v2/package/ 11405ms
> > > > [exec] Your package was pushed.
> > > > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
> > > > https://www.nuget.org/api/v2/package'...
> > > > [exec] PUT https://www.nuget.org/api/v2/package/
> > > > [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms
> > > > [exec] 409 (A package with ID 'Gremlin.Net.Template' and version
> > > > '3.4.0-rc2' already exists and cannot be modified.)
> > > >
> > > >
> > > > why is it trying to push the 3.4.0 line? looks like the error didn't
> > > > matter as the other two published fine, but let's fix the error if we
> > > > can...
> > > >
> > > > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT
> artifacts
> > > and
> > > >> docs too:
> > > >>
> > > >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/
> > > >>
> > > >>
> > > >>
> > > >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette <
> > spmalle...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> I just published final 3.3.4-SNAPSHOT artifacts and docs:
> > > >>>
> > > >>> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/
> > > >>>
> > > >>> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale
> > wrote:
> > > >>>
> > > I'll take 3.2.10.
> > >
> > > Robert Dale
> > >
> > >
> > > On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette <
> > spmalle...@gmail.com
> > > >
> > > wrote:
> > >
> > > > So - code freeze for the tp32 and tp33 branches is in effect at
> > this
> > > point.
> > > > We'll use this thread to discuss issues related to 3.2.10 and
> 3.3.4
> > > leading
> > > > up to the build of release artifacts for 10/15. We currently
> have a
> > > few PRs
> > > > that need merging to those branches,
> > > >
> > > > https://github.com/apache/tinkerpop/pull/952 (submit scripts
> with
> > >
Re: code freeze 3.2.10/3.3.4
You don't want to put https://issues.apache.org/jira/browse/TINKERPOP-2068
on tp32?
Robert Dale
On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette
wrote:
> > I created a ticket to track this and I can probably take care of it next
> week
>
> that makes sense, thank you.
>
> separately, code freeze is now lifted on tp33 - i've bumped to
> 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to go.
> I've left tp32 on 3.2.10 until we decide to actually do something on that
> branch. For now, we'll just say we're done there as we discussed
> elsethread.
>
> kuppitz, feel free to fire up the dead branch cleanup email. i wonder if it
> will be more convenient to delete branches as we go now that we have the
> github UI available to us. might be good to just hit the "delete branch"
> button right when we hit the merge one.
>
> i will announce the releases on monday morning EST time.
>
>
>
> On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann
> wrote:
>
> > We currently use this to push the package:
> >
> > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
> >
> > which pushes all NuGet packages starting with Gremlin.Net. You probably
> > also had the package for version 3.4.0-rc2 in that directory. So,
> > nuget.exe tried to push that version again which isn't allowed by NuGet
> > as packages are immutable for a given version.
> >
> > I guess we should specify the exact version here instead to avoid these
> > problems in the future. Otherwise we could push development versions to
> > nuget.org by accident. I probably implemented it like this at first
> > because I assumed that mvn clean would always remove older packages
> > which seems to be not the case here.
> >
> > Anyway, I created a ticket to track this and I can probably take care of
> > it next week:
> >
> > https://issues.apache.org/jira/browse/TINKERPOP-2074
> >
> >
> > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
> > > Florian, any idea what's going on with this error when i deployed
> 3.3.4:
> > >
> > > main:
> > > [echo] nuget.exe already downloaded.
> > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
> > > https://www.nuget.org/api/v2/package'...
> > > [exec] PUT https://www.nuget.org/api/v2/package/
> > > [exec] Created https://www.nuget.org/api/v2/package/ 1362ms
> > > [exec] Your package was pushed.
> > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
> > > https://www.nuget.org/api/v2/package'...
> > > [exec] PUT https://www.nuget.org/api/v2/package/
> > > [exec] Created https://www.nuget.org/api/v2/package/ 11405ms
> > > [exec] Your package was pushed.
> > > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
> > > https://www.nuget.org/api/v2/package'...
> > > [exec] PUT https://www.nuget.org/api/v2/package/
> > > [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms
> > > [exec] 409 (A package with ID 'Gremlin.Net.Template' and version
> > > '3.4.0-rc2' already exists and cannot be modified.)
> > >
> > >
> > > why is it trying to push the 3.4.0 line? looks like the error didn't
> > > matter as the other two published fine, but let's fix the error if we
> > > can...
> > >
> > > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette >
> > > wrote:
> > >
> > >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT artifacts
> > and
> > >> docs too:
> > >>
> > >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/
> > >>
> > >>
> > >>
> > >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette <
> spmalle...@gmail.com>
> > >> wrote:
> > >>
> > >>> I just published final 3.3.4-SNAPSHOT artifacts and docs:
> > >>>
> > >>> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/
> > >>>
> > >>> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale
> wrote:
> > >>>
> > I'll take 3.2.10.
> >
> > Robert Dale
> >
> >
> > On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette <
> spmalle...@gmail.com
> > >
> > wrote:
> >
> > > So - code freeze for the tp32 and tp33 branches is in effect at
> this
> > point.
> > > We'll use this thread to discuss issues related to 3.2.10 and 3.3.4
> > leading
> > > up to the build of release artifacts for 10/15. We currently have a
> > few PRs
> > > that need merging to those branches,
> > >
> > > https://github.com/apache/tinkerpop/pull/952 (submit scripts with
> > > gremlin-javascript)
> > > https://github.com/apache/tinkerpop/pull/953 (minor fix for
> testing
> > around
> > > inject in .net)
> > >
> > > but they are related to GLVs so we shouldn't be affecting the
> ability
> > of
> > > graph providers to test against the core code. If those merge
> during
> > code
> > > freeze, I don't think that's too big a problem.
> > >
> > > Note that the master branch will remain open for development during
> > this
> > > time period.
> > >
> > > Anyone care to volunteer for release manager du
Re: code freeze 3.2.10/3.3.4
> I created a ticket to track this and I can probably take care of it next
week
that makes sense, thank you.
separately, code freeze is now lifted on tp33 - i've bumped to
3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to go.
I've left tp32 on 3.2.10 until we decide to actually do something on that
branch. For now, we'll just say we're done there as we discussed
elsethread.
kuppitz, feel free to fire up the dead branch cleanup email. i wonder if it
will be more convenient to delete branches as we go now that we have the
github UI available to us. might be good to just hit the "delete branch"
button right when we hit the merge one.
i will announce the releases on monday morning EST time.
On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann
wrote:
> We currently use this to push the package:
>
> ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
>
> which pushes all NuGet packages starting with Gremlin.Net. You probably
> also had the package for version 3.4.0-rc2 in that directory. So,
> nuget.exe tried to push that version again which isn't allowed by NuGet
> as packages are immutable for a given version.
>
> I guess we should specify the exact version here instead to avoid these
> problems in the future. Otherwise we could push development versions to
> nuget.org by accident. I probably implemented it like this at first
> because I assumed that mvn clean would always remove older packages
> which seems to be not the case here.
>
> Anyway, I created a ticket to track this and I can probably take care of
> it next week:
>
> https://issues.apache.org/jira/browse/TINKERPOP-2074
>
>
> Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
> > Florian, any idea what's going on with this error when i deployed 3.3.4:
> >
> > main:
> > [echo] nuget.exe already downloaded.
> > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
> > https://www.nuget.org/api/v2/package'...
> > [exec] PUT https://www.nuget.org/api/v2/package/
> > [exec] Created https://www.nuget.org/api/v2/package/ 1362ms
> > [exec] Your package was pushed.
> > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
> > https://www.nuget.org/api/v2/package'...
> > [exec] PUT https://www.nuget.org/api/v2/package/
> > [exec] Created https://www.nuget.org/api/v2/package/ 11405ms
> > [exec] Your package was pushed.
> > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
> > https://www.nuget.org/api/v2/package'...
> > [exec] PUT https://www.nuget.org/api/v2/package/
> > [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms
> > [exec] 409 (A package with ID 'Gremlin.Net.Template' and version
> > '3.4.0-rc2' already exists and cannot be modified.)
> >
> >
> > why is it trying to push the 3.4.0 line? looks like the error didn't
> > matter as the other two published fine, but let's fix the error if we
> > can...
> >
> > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette
> > wrote:
> >
> >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT artifacts
> and
> >> docs too:
> >>
> >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/
> >>
> >>
> >>
> >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette
> >> wrote:
> >>
> >>> I just published final 3.3.4-SNAPSHOT artifacts and docs:
> >>>
> >>> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/
> >>>
> >>> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale wrote:
> >>>
> I'll take 3.2.10.
>
> Robert Dale
>
>
> On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette >
> wrote:
>
> > So - code freeze for the tp32 and tp33 branches is in effect at this
> point.
> > We'll use this thread to discuss issues related to 3.2.10 and 3.3.4
> leading
> > up to the build of release artifacts for 10/15. We currently have a
> few PRs
> > that need merging to those branches,
> >
> > https://github.com/apache/tinkerpop/pull/952 (submit scripts with
> > gremlin-javascript)
> > https://github.com/apache/tinkerpop/pull/953 (minor fix for testing
> around
> > inject in .net)
> >
> > but they are related to GLVs so we shouldn't be affecting the ability
> of
> > graph providers to test against the core code. If those merge during
> code
> > freeze, I don't think that's too big a problem.
> >
> > Note that the master branch will remain open for development during
> this
> > time period.
> >
> > Anyone care to volunteer for release manager duties for either of
> these
> > releases?
> >
>
>
Re: code freeze 3.2.10/3.3.4
We currently use this to push the package:
${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
which pushes all NuGet packages starting with Gremlin.Net. You probably
also had the package for version 3.4.0-rc2 in that directory. So,
nuget.exe tried to push that version again which isn't allowed by NuGet
as packages are immutable for a given version.
I guess we should specify the exact version here instead to avoid these
problems in the future. Otherwise we could push development versions to
nuget.org by accident. I probably implemented it like this at first
because I assumed that mvn clean would always remove older packages
which seems to be not the case here.
Anyway, I created a ticket to track this and I can probably take care of
it next week:
https://issues.apache.org/jira/browse/TINKERPOP-2074
Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
> Florian, any idea what's going on with this error when i deployed 3.3.4:
>
> main:
> [echo] nuget.exe already downloaded.
> [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
> https://www.nuget.org/api/v2/package'...
> [exec] PUT https://www.nuget.org/api/v2/package/
> [exec] Created https://www.nuget.org/api/v2/package/ 1362ms
> [exec] Your package was pushed.
> [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
> https://www.nuget.org/api/v2/package'...
> [exec] PUT https://www.nuget.org/api/v2/package/
> [exec] Created https://www.nuget.org/api/v2/package/ 11405ms
> [exec] Your package was pushed.
> [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
> https://www.nuget.org/api/v2/package'...
> [exec] PUT https://www.nuget.org/api/v2/package/
> [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms
> [exec] 409 (A package with ID 'Gremlin.Net.Template' and version
> '3.4.0-rc2' already exists and cannot be modified.)
>
>
> why is it trying to push the 3.4.0 line? looks like the error didn't
> matter as the other two published fine, but let's fix the error if we
> can...
>
> On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette
> wrote:
>
>> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT artifacts and
>> docs too:
>>
>> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/
>>
>>
>>
>> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette
>> wrote:
>>
>>> I just published final 3.3.4-SNAPSHOT artifacts and docs:
>>>
>>> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/
>>>
>>> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale wrote:
>>>
I'll take 3.2.10.
Robert Dale
On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette
wrote:
> So - code freeze for the tp32 and tp33 branches is in effect at this
point.
> We'll use this thread to discuss issues related to 3.2.10 and 3.3.4
leading
> up to the build of release artifacts for 10/15. We currently have a
few PRs
> that need merging to those branches,
>
> https://github.com/apache/tinkerpop/pull/952 (submit scripts with
> gremlin-javascript)
> https://github.com/apache/tinkerpop/pull/953 (minor fix for testing
around
> inject in .net)
>
> but they are related to GLVs so we shouldn't be affecting the ability
of
> graph providers to test against the core code. If those merge during
code
> freeze, I don't think that's too big a problem.
>
> Note that the master branch will remain open for development during
this
> time period.
>
> Anyone care to volunteer for release manager duties for either of these
> releases?
>
Re: code freeze 3.2.10/3.3.4
Florian, any idea what's going on with this error when i deployed 3.3.4: main: [echo] nuget.exe already downloaded. [exec] Pushing Gremlin.Net.3.3.4.nupkg to ' https://www.nuget.org/api/v2/package'... [exec] PUT https://www.nuget.org/api/v2/package/ [exec] Created https://www.nuget.org/api/v2/package/ 1362ms [exec] Your package was pushed. [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to ' https://www.nuget.org/api/v2/package'... [exec] PUT https://www.nuget.org/api/v2/package/ [exec] Created https://www.nuget.org/api/v2/package/ 11405ms [exec] Your package was pushed. [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to ' https://www.nuget.org/api/v2/package'... [exec] PUT https://www.nuget.org/api/v2/package/ [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms [exec] 409 (A package with ID 'Gremlin.Net.Template' and version '3.4.0-rc2' already exists and cannot be modified.) why is it trying to push the 3.4.0 line? looks like the error didn't matter as the other two published fine, but let's fix the error if we can... On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette wrote: > Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT artifacts and > docs too: > > http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/ > > > > On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette > wrote: > >> I just published final 3.3.4-SNAPSHOT artifacts and docs: >> >> http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/ >> >> On Sun, Oct 7, 2018 at 8:33 AM Robert Dale wrote: >> >>> I'll take 3.2.10. >>> >>> Robert Dale >>> >>> >>> On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette >>> wrote: >>> >>> > So - code freeze for the tp32 and tp33 branches is in effect at this >>> point. >>> > We'll use this thread to discuss issues related to 3.2.10 and 3.3.4 >>> leading >>> > up to the build of release artifacts for 10/15. We currently have a >>> few PRs >>> > that need merging to those branches, >>> > >>> > https://github.com/apache/tinkerpop/pull/952 (submit scripts with >>> > gremlin-javascript) >>> > https://github.com/apache/tinkerpop/pull/953 (minor fix for testing >>> around >>> > inject in .net) >>> > >>> > but they are related to GLVs so we shouldn't be affecting the ability >>> of >>> > graph providers to test against the core code. If those merge during >>> code >>> > freeze, I don't think that's too big a problem. >>> > >>> > Note that the master branch will remain open for development during >>> this >>> > time period. >>> > >>> > Anyone care to volunteer for release manager duties for either of these >>> > releases? >>> > >>> >>
Re: code freeze 3.2.10/3.3.4
Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT artifacts and docs too: http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/ On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette wrote: > I just published final 3.3.4-SNAPSHOT artifacts and docs: > > http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/ > > On Sun, Oct 7, 2018 at 8:33 AM Robert Dale wrote: > >> I'll take 3.2.10. >> >> Robert Dale >> >> >> On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette >> wrote: >> >> > So - code freeze for the tp32 and tp33 branches is in effect at this >> point. >> > We'll use this thread to discuss issues related to 3.2.10 and 3.3.4 >> leading >> > up to the build of release artifacts for 10/15. We currently have a few >> PRs >> > that need merging to those branches, >> > >> > https://github.com/apache/tinkerpop/pull/952 (submit scripts with >> > gremlin-javascript) >> > https://github.com/apache/tinkerpop/pull/953 (minor fix for testing >> around >> > inject in .net) >> > >> > but they are related to GLVs so we shouldn't be affecting the ability of >> > graph providers to test against the core code. If those merge during >> code >> > freeze, I don't think that's too big a problem. >> > >> > Note that the master branch will remain open for development during this >> > time period. >> > >> > Anyone care to volunteer for release manager duties for either of these >> > releases? >> > >> >
Re: code freeze 3.2.10/3.3.4
I just published final 3.3.4-SNAPSHOT artifacts and docs: http://tinkerpop.apache.org/docs/3.3.4-SNAPSHOT/ On Sun, Oct 7, 2018 at 8:33 AM Robert Dale wrote: > I'll take 3.2.10. > > Robert Dale > > > On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette > wrote: > > > So - code freeze for the tp32 and tp33 branches is in effect at this > point. > > We'll use this thread to discuss issues related to 3.2.10 and 3.3.4 > leading > > up to the build of release artifacts for 10/15. We currently have a few > PRs > > that need merging to those branches, > > > > https://github.com/apache/tinkerpop/pull/952 (submit scripts with > > gremlin-javascript) > > https://github.com/apache/tinkerpop/pull/953 (minor fix for testing > around > > inject in .net) > > > > but they are related to GLVs so we shouldn't be affecting the ability of > > graph providers to test against the core code. If those merge during code > > freeze, I don't think that's too big a problem. > > > > Note that the master branch will remain open for development during this > > time period. > > > > Anyone care to volunteer for release manager duties for either of these > > releases? > > >
Re: code freeze 3.2.10/3.3.4
I'll take 3.2.10. Robert Dale On Fri, Oct 5, 2018 at 7:40 PM Stephen Mallette wrote: > So - code freeze for the tp32 and tp33 branches is in effect at this point. > We'll use this thread to discuss issues related to 3.2.10 and 3.3.4 leading > up to the build of release artifacts for 10/15. We currently have a few PRs > that need merging to those branches, > > https://github.com/apache/tinkerpop/pull/952 (submit scripts with > gremlin-javascript) > https://github.com/apache/tinkerpop/pull/953 (minor fix for testing around > inject in .net) > > but they are related to GLVs so we shouldn't be affecting the ability of > graph providers to test against the core code. If those merge during code > freeze, I don't think that's too big a problem. > > Note that the master branch will remain open for development during this > time period. > > Anyone care to volunteer for release manager duties for either of these > releases? >
