As an FYI. I found some changes in 0.3 that will make my release notes not entirely accurate for the 0.3.2 and 0.4.0 releases. My plan is to open a PR updating RELEASING.md with my notes. I'll do my best to get it out this week, but it might be early next week.

I think you'll want to get #1601 in as well. Right now it shows test failures, but those are for extended tests from travis.yml.cassandra so those failures will need to get addressed in the release. It'll make it easier for you to test out all the Cassandra versions that we claim to support. Rather than doing a separate test in your local branch with the alternate travis config you could just add [full build] to your commit message.

I agree on not including #1547 and #1588. There's some testing going on into whether or not they're still necessary after #1606. The only other possible PR to go in seems like #1406?

On Thursday, May 30, 2019 at 7:49:50 AM UTC-7, Oleksandr Porunov wrote:

Hi everyone,

I am going to make "0.3.2" release PR after conflicts in #1609 is resolved and the PR is merged.

After that I am going to finalize artifacts, docs and start a voting process. 

I am going to use Chris' release notes listed here: https://github.com/chupman/janusgraph/blob/add-release-manager-instructions/janusgraph-release-notes.md

I have moved all opened issues from "0.3.2" milestone into "v0.3.x" milestone.

I have removed these two issues from milestones: #1547 and #1588 because they look more like features and I am not sure that they will be resolved soon (Of course I will be happy to review them when they are fixed). As I understand we re-targeted them from master into "0.3" because they are partially connected to the bugfix but on the other hand they are introducing a new parameter, so I don't know which branch they should be targeted. I am OK with both "0.3" and "master" branches.

Please, tell if we need to include something else into "0.3.2" release.

Estimated time for starting a release process is 1-2 days.

Best regards,

Oleksandr

Hi everyone,

I am going to make "0.3.2" release PR after conflicts in #1609 is resolved and the PR is merged.

After that I am going to finalize artifacts, docs and start a voting process. 

I am going to use Chris' release notes listed here: https://github.com/chupman/janusgraph/blob/add-release-manager-instructions/janusgraph-release-notes.md

I have moved all opened issues from "0.3.2" milestone into "v0.3.x" milestone.

I have removed these two issues from milestones: #1547 and #1588 because they look more like features and I am not sure that they will be resolved soon (Of course I will be happy to review them when they are fixed). As I understand we re-targeted them from master into "0.3" because they are partially connected to the bugfix but on the other hand they are introducing a new parameter, so I don't know which branch they should be targeted. I am OK with both "0.3" and "master" branches.

Please, tell if we need to include something else into "0.3.2" release.

Estimated time for starting a release process is 1-2 days.

Best regards,

Oleksandr

Hello,

We are happy to announce that JanusGraph 0.2.3 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2-doc.zip

        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.3

Please note that the v0.2.3 tag has been updated. You can refresh your tags with this command:

        git tag -l | xargs git tag -d && git fetch -t

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.3/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, May 24, 2018 at 6:45 PM PST.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My non-binding vote is +1.


Thank you,
Chris Hupman

I just tested to build the docker image for janusgraph and created a PR. The image works perfectly with my changes in PR https://github.com/JanusGraph/janusgraph-docker/pull/17.

My VOTE is +1.

I have downloaded .tar.zip, extracted it, built jars, included into my personal project with different integration tests. Ran integration tests. All tests have passed except some tests which require the fix #1501.

As this bug wasn't introduced in `0.2.3` and currently it is placed in all janusgraph versions (except current `0.3` and `master`) then I think it is OK.

My VOTE is +1.  

On Thursday, May 23, 2019 at 5:07:37 PM UTC+3, Florian Hockmann wrote:

I skimmed over the docs and everything looks as expected.

The changelog and the release on GitHub also look good.

I also downloaded the zip archive, extracted it, started JanusGraph with bin/janusgraph.sh and loaded a toy graph created with 0.2.2. Then I executed some example traversals and didn't run into any problems.

My VOTE is +1.

Am Mittwoch, 22. Mai 2019 22:31:05 UTC+2 schrieb Chris Hupman:

Thanks for catching that. It's been updated.

On Wed, May 22, 2019 at 12:58 PM Oleksandr Porunov <ale...@...> wrote:

Hello Chris,

Right now a small mistake in https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

It says: Version 0.2.2 (October 9, 2018)

I assume it should be: Version 0.2.3 (May 21, 2019)

On Wednesday, May 22, 2019 at 4:37:24 AM UTC+3, Chris Hupman wrote:

Hello,

We are happy to announce that JanusGraph 0.2.3 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2-doc.zip

        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.3

Please note that the v0.2.3 tag has been updated. You can refresh your tags with this command:

        git tag -l | xargs git tag -d && git fetch -t

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.3/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, May 24, 2018 at 6:45 PM PST.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My non-binding vote is +1.


Thank you,
Chris Hupman

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/ndOUqZ8sC5g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jan...@....
To post to this group, send email to jan...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/d39d69ac-f940-4ee3-b57f-908f8171bf9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I was looking into libthrift again and realized I did a bad job keeping up with us. Were most of the issues figured out in PR 1400 and PR 1436? What else is there to do before we can remove libthrift as a dependency in 0.4.0? 

On Wednesday, January 23, 2019 at 1:56:54 AM UTC-8, Florian Hockmann wrote:

but I do wonder how long we should continue to support things like thrift and upgrading from titan.

I think we should deprecate Thrift soon and then remove it in the next minor version of JanusGraph after that, but we probably need to offer the same functionality for CQL as for Thrift before we can deprecate Thrift. Since we currently don't support Spark without Thrift, we can't really deprecate it yet in my opinion. Another issue we may want to take into account when talking about deprecation / removal of Thrift is the reported performance decrease of CQL compared to Thrift: JanusGraph/janusgraph#1249

Now regarding, how to support CQL for Spark: I found out in the meantime that Cassandra removed all Thrift code from its CQL components already in version 2.2 with CASSANDRA-8358. This most likely means for us that we only have to update to Cassandra 2.2 to get full CQL support for Spark which also means that we don't have to do anything about Thrift right now as Thrift is still fully supported in Cassandra 2.2. We only have to decide about that when we actually update to Cassandra 3.0, but we can do that at a later point (ideally before Cassandra 4.0 will be released as support for Cassandra 2.1 and 2.2 will end with that release).

The current state of this work is that the update to Cassandra 2.2 led to build failures where I have no idea yet what's causing them. janusgraph-solr and some other projects that all depend on janusgraph-cassandra now fail with this error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.15:integration-test (default) on project janusgraph-solr: Execution default of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.15:integration-test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?

This commit introduced the problem. I found a lot of reports with similar problems, but none of the suggested solutions helped so far. It's also strange that janusgraph-cassandra itself doesn't fail with this error.

I already created a branch that includes the update to Cassandra 2.2 and an initial version of a CQL input format for Spark, but for some reason my tests aren''t executed:

Running org.janusgraph.hadoop.CqlInputFormatIT
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/travis/.m2/repository/org/slf4j/slf4j-log4j12/1.7.12/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/travis/.m2/repository/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Running org.janusgraph.hadoop.CassandraInputFormatIT

If anyone here has any helpful input on one of these two problems, then I would really appreciate that as I'm starting to run out of ideas here...

Am Mittwoch, 23. Januar 2019 03:44:40 UTC+1 schrieb Chris Hupman:

+1 for number 3.

Number 3 is probably the best option, but I do wonder how long we should continue to support things like thrift and upgrading from titan. 

On Wednesday, January 9, 2019 at 3:02:50 AM UTC-8, Florian Hockmann wrote:

Hi,
Jan Jansen (farodin91) and I took a first try at implementing a CQL input format for Spark to enable OLAP jobs to work without Thrift (#985). Unfortunately, we can't just add wrappers for the CQL OLAP support in org.apache.cassandra and be done with it. The reason is that JanusGraph still uses version 2.1.20 of org.apache.cassandra cassandra-all which is not compatible with the version of the DataStax Cassandra driver JanusGraph is using. So, we need to update the org.apache.cassandra dependency to major version 3.
With this update we would however lose support for Thrift as that was thrown out completely in version 3.0.0 (see CASSANDRA-9353). That leaves us with the following options:

1. Update the dependency and drop support for Thrift. Thrift is deprecated since Cassandra 3.0 which was released in November 2015. Users who want to continue using Thrift could stay on a JanusGraph version that still supports it.
2. Create a separate project janusgraph-hadoop-cql that can use newer versions of these two dependencies without affecting the Thrift support in janusgraph-hadoop-core.
3. Update the dependency and include the classes for Thrift support from org.apache.cassandra.hadoop package in janusgraph-hadoop-core.
   

The first option would of course be the easiest to implement and I think that dropping support for Thrift over 3 years after deprecation started and only in a new major release of JanusGraph would be acceptable. However, this comes with some risk as we would make CQL the only way to use OLAP with Cassandra in the same version in which we introduce the CQL OLAP support. So, if we find any problems with the implementation, then users could only downgrade to a lower version of JanusGraph that still supports Thrift as there wouldn’t be an alternative input format left.
We should probably update the dependency at some point irrespective of the support for CQL any way so creating a new project now just to not update the dependency in janusgraph-hadoop-core probably isn’t the best idea.
That is why option 3 sounds like the best one to us. We would add support for OLAP with CQL without losing support for Thrift which we could drop at any time in the future.

Any thoughts or other opinions on this topic?

but I do wonder how long we should continue to support things like thrift and upgrading from titan.

I think we should deprecate Thrift soon and then remove it in the next minor version of JanusGraph after that, but we probably need to offer the same functionality for CQL as for Thrift before we can deprecate Thrift. Since we currently don't support Spark without Thrift, we can't really deprecate it yet in my opinion. Another issue we may want to take into account when talking about deprecation / removal of Thrift is the reported performance decrease of CQL compared to Thrift: JanusGraph/janusgraph#1249

Now regarding, how to support CQL for Spark: I found out in the meantime that Cassandra removed all Thrift code from its CQL components already in version 2.2 with CASSANDRA-8358. This most likely means for us that we only have to update to Cassandra 2.2 to get full CQL support for Spark which also means that we don't have to do anything about Thrift right now as Thrift is still fully supported in Cassandra 2.2. We only have to decide about that when we actually update to Cassandra 3.0, but we can do that at a later point (ideally before Cassandra 4.0 will be released as support for Cassandra 2.1 and 2.2 will end with that release).

The current state of this work is that the update to Cassandra 2.2 led to build failures where I have no idea yet what's causing them. janusgraph-solr and some other projects that all depend on janusgraph-cassandra now fail with this error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.15:integration-test (default) on project janusgraph-solr: Execution default of goal
org.apache.maven.plugins:maven-failsafe-plugin:2.15:integration-test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?

This commit introduced the problem. I found a lot of reports with similar problems, but none of the suggested solutions helped so far. It's also strange that janusgraph-cassandra itself doesn't fail with this error.

I already created a branch that includes the update to Cassandra 2.2 and an initial version of a CQL input format for Spark, but for some reason my tests aren''t executed:

Running org.janusgraph.hadoop.CqlInputFormatIT
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/travis/.m2/repository/org/slf4j/slf4j-log4j12/1.7.12/slf4j-log4j12-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/travis/.m2/repository/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Running org.janusgraph.hadoop.CassandraInputFormatIT

If anyone here has any helpful input on one of these two problems, then I would really appreciate that as I'm starting to run out of ideas here...

Am Mittwoch, 23. Januar 2019 03:44:40 UTC+1 schrieb Chris Hupman:

+1 for number 3.

Number 3 is probably the best option, but I do wonder how long we should continue to support things like thrift and upgrading from titan. 

On Wednesday, January 9, 2019 at 3:02:50 AM UTC-8, Florian Hockmann wrote:

Hi,
Jan Jansen (farodin91) and I took a first try at implementing a CQL input format for Spark to enable OLAP jobs to work without Thrift (#985). Unfortunately, we can't just add wrappers for the CQL OLAP support in org.apache.cassandra and be done with it. The reason is that JanusGraph still uses version 2.1.20 of org.apache.cassandra cassandra-all which is not compatible with the version of the DataStax Cassandra driver JanusGraph is using. So, we need to update the org.apache.cassandra dependency to major version 3.
With this update we would however lose support for Thrift as that was thrown out completely in version 3.0.0 (see CASSANDRA-9353). That leaves us with the following options:

1. Update the dependency and drop support for Thrift. Thrift is deprecated since Cassandra 3.0 which was released in November 2015. Users who want to continue using Thrift could stay on a JanusGraph version that still supports it.
2. Create a separate project janusgraph-hadoop-cql that can use newer versions of these two dependencies without affecting the Thrift support in janusgraph-hadoop-core.
3. Update the dependency and include the classes for Thrift support from org.apache.cassandra.hadoop package in janusgraph-hadoop-core.
   

The first option would of course be the easiest to implement and I think that dropping support for Thrift over 3 years after deprecation started and only in a new major release of JanusGraph would be acceptable. However, this comes with some risk as we would make CQL the only way to use OLAP with Cassandra in the same version in which we introduce the CQL OLAP support. So, if we find any problems with the implementation, then users could only downgrade to a lower version of JanusGraph that still supports Thrift as there wouldn’t be an alternative input format left.
We should probably update the dependency at some point irrespective of the support for CQL any way so creating a new project now just to not update the dependency in janusgraph-hadoop-core probably isn’t the best idea.
That is why option 3 sounds like the best one to us. We would add support for OLAP with CQL without losing support for Thrift which we could drop at any time in the future.

Any thoughts or other opinions on this topic?

I skimmed over the docs and everything looks as expected.

The changelog and the release on GitHub also look good.

I also downloaded the zip archive, extracted it, started JanusGraph with bin/janusgraph.sh and loaded a toy graph created with 0.2.2. Then I executed some example traversals and didn't run into any problems.

My VOTE is +1.

Am Mittwoch, 22. Mai 2019 22:31:05 UTC+2 schrieb Chris Hupman:

Thanks for catching that. It's been updated.

On Wed, May 22, 2019 at 12:58 PM Oleksandr Porunov <ale...@...> wrote:

Hello Chris,

Right now a small mistake in https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

It says: Version 0.2.2 (October 9, 2018)

I assume it should be: Version 0.2.3 (May 21, 2019)

On Wednesday, May 22, 2019 at 4:37:24 AM UTC+3, Chris Hupman wrote:

Hello,

We are happy to announce that JanusGraph 0.2.3 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2-doc.zip

        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.3

Please note that the v0.2.3 tag has been updated. You can refresh your tags with this command:

        git tag -l | xargs git tag -d && git fetch -t

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.3/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, May 24, 2018 at 6:45 PM PST.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My non-binding vote is +1.


Thank you,
Chris Hupman

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/ndOUqZ8sC5g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jan...@....
To post to this group, send email to jan...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/d39d69ac-f940-4ee3-b57f-908f8171bf9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks for catching that. It's been updated.

On Wed, May 22, 2019 at 12:58 PM Oleksandr Porunov <ale...@...> wrote:

Hello Chris,

Right now a small mistake in https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

It says: Version 0.2.2 (October 9, 2018)

I assume it should be: Version 0.2.3 (May 21, 2019)

On Wednesday, May 22, 2019 at 4:37:24 AM UTC+3, Chris Hupman wrote:

Hello,

We are happy to announce that JanusGraph 0.2.3 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2-doc.zip

        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.3

Please note that the v0.2.3 tag has been updated. You can refresh your tags with this command:

        git tag -l | xargs git tag -d && git fetch -t

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.3/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, May 24, 2018 at 6:45 PM PST.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My non-binding vote is +1.


Thank you,
Chris Hupman

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/ndOUqZ8sC5g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgr...@googlegroups.com.
To post to this group, send email to janusgr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/d39d69ac-f940-4ee3-b57f-908f8171bf9e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hello,

We are happy to announce that JanusGraph 0.2.3 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.3

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.3/janusgraph-0.2.3-hadoop2-doc.zip

        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.3

Please note that the v0.2.3 tag has been updated. You can refresh your tags with this command:

        git tag -l | xargs git tag -d && git fetch -t

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.3/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, May 24, 2018 at 6:45 PM PST.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My non-binding vote is +1.


Thank you,
Chris Hupman

Chris, thank you for this work! Sure, take as much time as you need!

On Tuesday, May 21, 2019 at 1:19:19 AM UTC+3, Chris Hupman wrote:

I will not be able to submit for a vote today. I realized I needed to do additional testing on Cassandra versions, using travis.yml.cassandra, and I got some failures in cql for version 3.11.0. I'm tracking down what's causing the issue and will hopefully be able to come up with a fix tomorrow. I'm also taking notes in hopes of saving Oleksandr and Florian some headaches on 0.3.2 and 0.4.0. 

On Friday, May 17, 2019 at 12:37:28 PM UTC-7, Chris Hupman wrote:

I'm hoping to submit for a vote on Monday. One piece of advice that I wish I had done is to pick a cutoff date where you'll push everything out to the next release so you don't have to worry about last minute additions. Then you can build your artifacts, draft your release, and start your vote. To put out a release it requires approval from 3 TSC members.

If you haven't already one thing that needs to be done is to add the milestone tag to all the 0.3 specific commits since 0.3.1 and their corresponding issues.

On Friday, May 17, 2019 at 12:19:54 PM UTC-7, Oleksandr Porunov wrote:

Notice, that PRs 1547 and 1588 are targeting master branch (which is 0.4.0 release). If you want those PRs to be included into 0.3.2 and 0.4.0 releases you should rebase your PRs and target 0.3 branch.

On Friday, May 17, 2019 at 9:46:28 PM UTC+3, Christopher Jackson wrote:

What is the current timeframe for the next 0.3 release? erinc just submitted 2 PRs that are crucial for our product release slated for June end. Would it be possible to have an early June 0.3.x release?

On Friday, February 8, 2019 at 8:47:30 AM UTC-5, Florian Hockmann wrote:

I just created a 0.3 branch and bumped master to 0.4.0-SNAPSHOT so we can make breaking changes and upgrade TinkerPop to version 3.4.0. This means that we now have 3 active release branches:

• master
• 0.3
• 0.2

For the 0.2 branch, we decided already that it hits EOL with the next 0.2.3 version. This leaves us with the question whether we want to merge bug fixes also into the 0.2 branch until we release 0.2.3 or whether we just want to freeze it as is and release 0.2.3 in its current state. In that case we could also release 0.2.3 very shortly and then close the 0.2 branch.

My suggestion here is that we don't target 0.2 for any new pull requests and release 0.2.3 shortly so we can close that branch as maintaining 3 release branches requires too much effort in my opinion. There are currently 6 pull requests open with bug fixes of which two already target the 0.2 branch:

• issue-357: Fix NullPointerException in loadRelations() #362
• Prevent deadlock when vertices are removed in parallel #1380

We're waiting in both PRs for the contributor to address review comments. If those are addressed until we start the VOTE for the 0.2.3, then I'd say that we merge them in and otherwise we can just merge them any time into 0.3.

The next question is which contributions should go into the 0.3 branch, in addition to master. When the 0.2 branch was created, there was a consensus to only merge contributions into master and use the 0.2 branch solely for bug fixes. I recently also documented this in our CONTRIBUTING.md:

First, you need to decide which release branch (e.g., master, 0.2) to create the feature branch from. If you intend to add a new feature, then master is the right branch. Bug fixes however should also be applied to other releases, so you should create your feature branch from the release branch with the lowest version number that is still active (e.g., 0.2).

However, we didn't strictly follow this decision and also merged some new features into 0.2 so we might want to discuss this branching and release strategy in general again for the 0.3 branch.

Do we want to stay with our earlier decision to only apply contributions to master and use other release branches only for bug fixes? Or are there good arguments to also apply other contributions like new features or dependency updates to other release branches, like 0.3?

In case we decide to only apply bug fixes to the 0.3 branch, will that take effect now or only after the 0.4.0 release?

I'm personally in favour of staying with our policy of applying contributions only to master, except for bug fixes which should also go to other active release branches, like 0.3 right now. Applying contributions also to other release branches just increases the overhead for contributors and since we usually don't have that many breaking changes in a new minor version, I also don't see why we shouldn't expect users to just update to the newest version.

Lastly regarding whether we want to still merge all contributions into the 0.3 branch until we have a 0.4.0 release, I'm leaning against that as it would require all contributors of open PR to change the target branch and it would also lead to confusion why our usual policy of only applying contributions to master doesn't apply here.

So, in short I propose the following:

1. We start release preparations for 0.2.3 shortly and close the 0.2 branch afterwards.
2. 0.3 only gets bug fixes from now on.
3. All other contributions only go into master.

Does that sound ok to everybody?

I will not be able to submit for a vote today. I realized I needed to do additional testing on Cassandra versions, using travis.yml.cassandra, and I got some failures in cql for version 3.11.0. I'm tracking down what's causing the issue and will hopefully be able to come up with a fix tomorrow. I'm also taking notes in hopes of saving Oleksandr and Florian some headaches on 0.3.2 and 0.4.0. 

On Friday, May 17, 2019 at 12:37:28 PM UTC-7, Chris Hupman wrote:

I'm hoping to submit for a vote on Monday. One piece of advice that I wish I had done is to pick a cutoff date where you'll push everything out to the next release so you don't have to worry about last minute additions. Then you can build your artifacts, draft your release, and start your vote. To put out a release it requires approval from 3 TSC members.

If you haven't already one thing that needs to be done is to add the milestone tag to all the 0.3 specific commits since 0.3.1 and their corresponding issues.

On Friday, May 17, 2019 at 12:19:54 PM UTC-7, Oleksandr Porunov wrote:

Notice, that PRs 1547 and 1588 are targeting master branch (which is 0.4.0 release). If you want those PRs to be included into 0.3.2 and 0.4.0 releases you should rebase your PRs and target 0.3 branch.

On Friday, May 17, 2019 at 9:46:28 PM UTC+3, Christopher Jackson wrote:

What is the current timeframe for the next 0.3 release? erinc just submitted 2 PRs that are crucial for our product release slated for June end. Would it be possible to have an early June 0.3.x release?

On Friday, February 8, 2019 at 8:47:30 AM UTC-5, Florian Hockmann wrote:

I just created a 0.3 branch and bumped master to 0.4.0-SNAPSHOT so we can make breaking changes and upgrade TinkerPop to version 3.4.0. This means that we now have 3 active release branches:

• master
• 0.3
• 0.2

For the 0.2 branch, we decided already that it hits EOL with the next 0.2.3 version. This leaves us with the question whether we want to merge bug fixes also into the 0.2 branch until we release 0.2.3 or whether we just want to freeze it as is and release 0.2.3 in its current state. In that case we could also release 0.2.3 very shortly and then close the 0.2 branch.

My suggestion here is that we don't target 0.2 for any new pull requests and release 0.2.3 shortly so we can close that branch as maintaining 3 release branches requires too much effort in my opinion. There are currently 6 pull requests open with bug fixes of which two already target the 0.2 branch:

• issue-357: Fix NullPointerException in loadRelations() #362
• Prevent deadlock when vertices are removed in parallel #1380

We're waiting in both PRs for the contributor to address review comments. If those are addressed until we start the VOTE for the 0.2.3, then I'd say that we merge them in and otherwise we can just merge them any time into 0.3.

The next question is which contributions should go into the 0.3 branch, in addition to master. When the 0.2 branch was created, there was a consensus to only merge contributions into master and use the 0.2 branch solely for bug fixes. I recently also documented this in our CONTRIBUTING.md:

First, you need to decide which release branch (e.g., master, 0.2) to create the feature branch from. If you intend to add a new feature, then master is the right branch. Bug fixes however should also be applied to other releases, so you should create your feature branch from the release branch with the lowest version number that is still active (e.g., 0.2).

However, we didn't strictly follow this decision and also merged some new features into 0.2 so we might want to discuss this branching and release strategy in general again for the 0.3 branch.

Do we want to stay with our earlier decision to only apply contributions to master and use other release branches only for bug fixes? Or are there good arguments to also apply other contributions like new features or dependency updates to other release branches, like 0.3?

In case we decide to only apply bug fixes to the 0.3 branch, will that take effect now or only after the 0.4.0 release?

I'm personally in favour of staying with our policy of applying contributions only to master, except for bug fixes which should also go to other active release branches, like 0.3 right now. Applying contributions also to other release branches just increases the overhead for contributors and since we usually don't have that many breaking changes in a new minor version, I also don't see why we shouldn't expect users to just update to the newest version.

Lastly regarding whether we want to still merge all contributions into the 0.3 branch until we have a 0.4.0 release, I'm leaning against that as it would require all contributors of open PR to change the target branch and it would also lead to confusion why our usual policy of only applying contributions to master doesn't apply here.

So, in short I propose the following:

1. We start release preparations for 0.2.3 shortly and close the 0.2 branch afterwards.
2. 0.3 only gets bug fixes from now on.
3. All other contributions only go into master.

Does that sound ok to everybody?

I'm hoping to submit for a vote on Monday. One piece of advice that I wish I had done is to pick a cutoff date where you'll push everything out to the next release so you don't have to worry about last minute additions. Then you can build your artifacts, draft your release, and start your vote. To put out a release it requires approval from 3 TSC members.

If you haven't already one thing that needs to be done is to add the milestone tag to all the 0.3 specific commits since 0.3.1 and their corresponding issues.

On Friday, May 17, 2019 at 12:19:54 PM UTC-7, Oleksandr Porunov wrote:

Notice, that PRs 1547 and 1588 are targeting master branch (which is 0.4.0 release). If you want those PRs to be included into 0.3.2 and 0.4.0 releases you should rebase your PRs and target 0.3 branch.

On Friday, May 17, 2019 at 9:46:28 PM UTC+3, Christopher Jackson wrote:

What is the current timeframe for the next 0.3 release? erinc just submitted 2 PRs that are crucial for our product release slated for June end. Would it be possible to have an early June 0.3.x release?

On Friday, February 8, 2019 at 8:47:30 AM UTC-5, Florian Hockmann wrote:

I just created a 0.3 branch and bumped master to 0.4.0-SNAPSHOT so we can make breaking changes and upgrade TinkerPop to version 3.4.0. This means that we now have 3 active release branches:

• master
• 0.3
• 0.2

For the 0.2 branch, we decided already that it hits EOL with the next 0.2.3 version. This leaves us with the question whether we want to merge bug fixes also into the 0.2 branch until we release 0.2.3 or whether we just want to freeze it as is and release 0.2.3 in its current state. In that case we could also release 0.2.3 very shortly and then close the 0.2 branch.

My suggestion here is that we don't target 0.2 for any new pull requests and release 0.2.3 shortly so we can close that branch as maintaining 3 release branches requires too much effort in my opinion. There are currently 6 pull requests open with bug fixes of which two already target the 0.2 branch:

• issue-357: Fix NullPointerException in loadRelations() #362
• Prevent deadlock when vertices are removed in parallel #1380

We're waiting in both PRs for the contributor to address review comments. If those are addressed until we start the VOTE for the 0.2.3, then I'd say that we merge them in and otherwise we can just merge them any time into 0.3.

The next question is which contributions should go into the 0.3 branch, in addition to master. When the 0.2 branch was created, there was a consensus to only merge contributions into master and use the 0.2 branch solely for bug fixes. I recently also documented this in our CONTRIBUTING.md:

First, you need to decide which release branch (e.g., master, 0.2) to create the feature branch from. If you intend to add a new feature, then master is the right branch. Bug fixes however should also be applied to other releases, so you should create your feature branch from the release branch with the lowest version number that is still active (e.g., 0.2).

However, we didn't strictly follow this decision and also merged some new features into 0.2 so we might want to discuss this branching and release strategy in general again for the 0.3 branch.

Do we want to stay with our earlier decision to only apply contributions to master and use other release branches only for bug fixes? Or are there good arguments to also apply other contributions like new features or dependency updates to other release branches, like 0.3?

In case we decide to only apply bug fixes to the 0.3 branch, will that take effect now or only after the 0.4.0 release?

I'm personally in favour of staying with our policy of applying contributions only to master, except for bug fixes which should also go to other active release branches, like 0.3 right now. Applying contributions also to other release branches just increases the overhead for contributors and since we usually don't have that many breaking changes in a new minor version, I also don't see why we shouldn't expect users to just update to the newest version.

Lastly regarding whether we want to still merge all contributions into the 0.3 branch until we have a 0.4.0 release, I'm leaning against that as it would require all contributors of open PR to change the target branch and it would also lead to confusion why our usual policy of only applying contributions to master doesn't apply here.

So, in short I propose the following:

1. We start release preparations for 0.2.3 shortly and close the 0.2 branch afterwards.
2. 0.3 only gets bug fixes from now on.
3. All other contributions only go into master.

Does that sound ok to everybody?

Notice, that PRs 1547 and 1588 are targeting master branch (which is 0.4.0 release). If you want those PRs to be included into 0.3.2 and 0.4.0 releases you should rebase your PRs and target 0.3 branch.

On Friday, May 17, 2019 at 9:46:28 PM UTC+3, Christopher Jackson wrote:

What is the current timeframe for the next 0.3 release? erinc just submitted 2 PRs that are crucial for our product release slated for June end. Would it be possible to have an early June 0.3.x release?

On Friday, February 8, 2019 at 8:47:30 AM UTC-5, Florian Hockmann wrote:

I just created a 0.3 branch and bumped master to 0.4.0-SNAPSHOT so we can make breaking changes and upgrade TinkerPop to version 3.4.0. This means that we now have 3 active release branches:

• master
• 0.3
• 0.2

For the 0.2 branch, we decided already that it hits EOL with the next 0.2.3 version. This leaves us with the question whether we want to merge bug fixes also into the 0.2 branch until we release 0.2.3 or whether we just want to freeze it as is and release 0.2.3 in its current state. In that case we could also release 0.2.3 very shortly and then close the 0.2 branch.

My suggestion here is that we don't target 0.2 for any new pull requests and release 0.2.3 shortly so we can close that branch as maintaining 3 release branches requires too much effort in my opinion. There are currently 6 pull requests open with bug fixes of which two already target the 0.2 branch:

• issue-357: Fix NullPointerException in loadRelations() #362
• Prevent deadlock when vertices are removed in parallel #1380

We're waiting in both PRs for the contributor to address review comments. If those are addressed until we start the VOTE for the 0.2.3, then I'd say that we merge them in and otherwise we can just merge them any time into 0.3.

The next question is which contributions should go into the 0.3 branch, in addition to master. When the 0.2 branch was created, there was a consensus to only merge contributions into master and use the 0.2 branch solely for bug fixes. I recently also documented this in our CONTRIBUTING.md:

First, you need to decide which release branch (e.g., master, 0.2) to create the feature branch from. If you intend to add a new feature, then master is the right branch. Bug fixes however should also be applied to other releases, so you should create your feature branch from the release branch with the lowest version number that is still active (e.g., 0.2).

However, we didn't strictly follow this decision and also merged some new features into 0.2 so we might want to discuss this branching and release strategy in general again for the 0.3 branch.

Do we want to stay with our earlier decision to only apply contributions to master and use other release branches only for bug fixes? Or are there good arguments to also apply other contributions like new features or dependency updates to other release branches, like 0.3?

In case we decide to only apply bug fixes to the 0.3 branch, will that take effect now or only after the 0.4.0 release?

I'm personally in favour of staying with our policy of applying contributions only to master, except for bug fixes which should also go to other active release branches, like 0.3 right now. Applying contributions also to other release branches just increases the overhead for contributors and since we usually don't have that many breaking changes in a new minor version, I also don't see why we shouldn't expect users to just update to the newest version.

Lastly regarding whether we want to still merge all contributions into the 0.3 branch until we have a 0.4.0 release, I'm leaning against that as it would require all contributors of open PR to change the target branch and it would also lead to confusion why our usual policy of only applying contributions to master doesn't apply here.

So, in short I propose the following:

1. We start release preparations for 0.2.3 shortly and close the 0.2 branch afterwards.
2. 0.3 only gets bug fixes from now on.
3. All other contributions only go into master.

Does that sound ok to everybody?

What is the current timeframe for the next 0.3 release? erinc just submitted 2 PRs that are crucial for our product release slated for June end. Would it be possible to have an early June 0.3.x release?

On Friday, February 8, 2019 at 8:47:30 AM UTC-5, Florian Hockmann wrote:

I just created a 0.3 branch and bumped master to 0.4.0-SNAPSHOT so we can make breaking changes and upgrade TinkerPop to version 3.4.0. This means that we now have 3 active release branches:

• master
• 0.3
• 0.2

For the 0.2 branch, we decided already that it hits EOL with the next 0.2.3 version. This leaves us with the question whether we want to merge bug fixes also into the 0.2 branch until we release 0.2.3 or whether we just want to freeze it as is and release 0.2.3 in its current state. In that case we could also release 0.2.3 very shortly and then close the 0.2 branch.

My suggestion here is that we don't target 0.2 for any new pull requests and release 0.2.3 shortly so we can close that branch as maintaining 3 release branches requires too much effort in my opinion. There are currently 6 pull requests open with bug fixes of which two already target the 0.2 branch:

• issue-357: Fix NullPointerException in loadRelations() #362
• Prevent deadlock when vertices are removed in parallel #1380

We're waiting in both PRs for the contributor to address review comments. If those are addressed until we start the VOTE for the 0.2.3, then I'd say that we merge them in and otherwise we can just merge them any time into 0.3.

The next question is which contributions should go into the 0.3 branch, in addition to master. When the 0.2 branch was created, there was a consensus to only merge contributions into master and use the 0.2 branch solely for bug fixes. I recently also documented this in our CONTRIBUTING.md:

First, you need to decide which release branch (e.g., master, 0.2) to create the feature branch from. If you intend to add a new feature, then master is the right branch. Bug fixes however should also be applied to other releases, so you should create your feature branch from the release branch with the lowest version number that is still active (e.g., 0.2).

However, we didn't strictly follow this decision and also merged some new features into 0.2 so we might want to discuss this branching and release strategy in general again for the 0.3 branch.

Do we want to stay with our earlier decision to only apply contributions to master and use other release branches only for bug fixes? Or are there good arguments to also apply other contributions like new features or dependency updates to other release branches, like 0.3?

In case we decide to only apply bug fixes to the 0.3 branch, will that take effect now or only after the 0.4.0 release?

I'm personally in favour of staying with our policy of applying contributions only to master, except for bug fixes which should also go to other active release branches, like 0.3 right now. Applying contributions also to other release branches just increases the overhead for contributors and since we usually don't have that many breaking changes in a new minor version, I also don't see why we shouldn't expect users to just update to the newest version.

Lastly regarding whether we want to still merge all contributions into the 0.3 branch until we have a 0.4.0 release, I'm leaning against that as it would require all contributors of open PR to change the target branch and it would also lead to confusion why our usual policy of only applying contributions to master doesn't apply here.

So, in short I propose the following:

1. We start release preparations for 0.2.3 shortly and close the 0.2 branch afterwards.
2. 0.3 only gets bug fixes from now on.
3. All other contributions only go into master.

Does that sound ok to everybody?