There are currently 2 PRs targeting the 0.2 branch:

• Modernize Documentation using mkdocs #1437
• Convert HBase TTL param from Integer to long JanusGraph#1454 #1456

These two could probably also be rebased on 0.3 so that shouldn't stop the 0.2.3 release.

I can of course start the VOTE thread for 0.2.3, but I can't really do the release itself as I haven't done that yet and our releasing docs seem to be pretty outdated. So, I need at least some help from someone who has already performed a release.

Jason, Ted and Misha, you seem to be the only ones who have actually done releases: Would you prefer if we release 0.2.3 shortly to close off the branch or to release it together with 0.3.2 and 0.4.0?

Am Mittwoch, 13. März 2019 13:38:16 UTC+1 schrieb Oleksandr Porunov:

Florian, can you setup a date for starting preparations for 0.2.3 release?

On Friday, February 8, 2019 at 8:04:50 PM UTC+2, Oleksandr Porunov wrote:

All suggestions look good to me. Thanks for starting the topic.

On Friday, February 8, 2019 at 3:47:30 PM UTC+2, 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?

Florian, can you setup a date for starting preparations for 0.2.3 release?

On Friday, February 8, 2019 at 8:04:50 PM UTC+2, Oleksandr Porunov wrote:

All suggestions look good to me. Thanks for starting the topic.

On Friday, February 8, 2019 at 3:47:30 PM UTC+2, 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?

All suggestions look good to me. Thanks for starting the topic.

On Friday, February 8, 2019 at 3:47:30 PM UTC+2, 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 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?