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?