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?

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 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?

Hi guys,

I just had a short call with Jason about what is required for releases and wanted to share my notes. I'm back from vacation and plan to get the process started this week.

JanusGraph Release checklist

• Start up new janusgraph-dev thread on release proposing what should be included in the release and asking for additional feedback and suggestions
• Make sure all PRs and issues added since last release are associated to the milestone
• Complete all items associated with milestone or move to a new milestone if necessary
• Write up a synopsis of changes made in release for release page and vote thread
• validate all changes have been merged upstream
• create janusgraph-dev vote thread and get required votes
• Tag release
• Draft release and upload artifacts
• Upload to sonatype

Cheers,

Chris

On Thursday, April 11, 2019 at 11:24:42 AM UTC-7, Jan Jansen wrote:

Hi
It would be cool to get the documentation ready for the release of version 0.3.2.
Therfefore, It would be cool, if some of the JanusGraph folks checks the documentation.

Afterwards, We can merge it, so we can integrate all changes of 0.3 docs. Followed by preparation for 0.4.

Dear

Jan Jansen

Hi
It would be cool to get the documentation ready for the release of version 0.3.2.
Therfefore, It would be cool, if some of the JanusGraph folks checks the documentation.

Afterwards, We can merge it, so we can integrate all changes of 0.3 docs. Followed by preparation for 0.4.

Dear

Jan Jansen

I can definitely take over one release and both the order and also the assignment of release managers you proposed, Oleksandr, sound good to me!

Am Donnerstag, 11. April 2019 16:40:02 UTC+2 schrieb Chris Hupman:

I actually had the same order in mind. I'm hoping to finish up the testing on my open service wrapper PR next week and then work on noarch rpm and Deb packages to add to the releases. If we all agree about adding the packages I'm a blocker anyways.

While I do have a direct channel to Jason I'll still try to ask the relevant questions in this thread or a new one so everyone can have access to the information.

Chris

On Thu, Apr 11, 2019, 3:00 AM Oleksandr Porunov <ale...@...> wrote:

Thank you Jason!

Waiting for your notes.

I also think that we should release 0.2.3 then 0.3.2 then 0.4.0 so that users wouldn't be confused which one is the latest and which one they should use.

I would volunteer to be a release manager for 0.3.2. Basically, it doesn't matter to me which release to take I just think that all 3 new members should take 1 release each so that we all had some experience with publishing new releases.

My thoughts are the next:

Chris could take 0.2.3 release and prepare it first. I assume he has some direct connection with you, so if he would have some problem with the release, you could help him because you already prepared 5 last releases.

Florian made the main work for 0.4.0 release (update tinkerpop to 3.4.x, support cql for olap), so I assume he could be a release manager for this version.

I could be in the middle and take 0.3.2 release.

Chris, Florian, what do you think about such scheme? Chris - 0.2.3, Me - 0.3.2, Florian - 0.4.0.

I am OK with another order as well if someone wants to propose another order.

On Wednesday, April 10, 2019 at 5:49:35 PM UTC+3, Jason Plurad wrote:

All three have been added to the JanusGraph org https://issues.sonatype.org/browse/OSSRH-47679

Splitting up the release management duties sounds good. Do we have volunteer release managers for each release? The biggest chore of course is finalizing the release content and pushing those PRs to completion. I will get a PR submitted this week with my notes for the mechanics of the release process.

I don't think we need to coordinate a single day release for the different branches. The main thing would be to stress which one is actually the most current release, since GitHub will flag the last published as the latest.

On Thursday, April 4, 2019 at 7:42:01 PM UTC-4, Chris Hupman wrote:

If the plan is to split it up I'm more than willing to take one of the releases. My username is chupman.

On Thursday, April 4, 2019 at 1:31:01 AM UTC-7, Florian Hockmann wrote:

I could do the next line of releases. But if someone else wants to, then feel free to do so.

Jason: Would you say that it makes sense for a single committer to do all three releases or could it make sense to split this up so that one takes care of 0.2.3, one of 0.3.2 and one of 0.4.0? The release process sounds quite time consuming, especially if one person does all three releases.

I think it makes sense in general to have multiple committers being able to perform releases. So it would be good if you could create an issue to give us the necessary permissions. Maybe wait a few days in case other committers are also interested in being able to do releases.

My account id is: florianhockmann

Am Mittwoch, 3. April 2019 18:54:13 UTC+2 schrieb Oleksandr Porunov:

Hello Jason,

Thank you for your response. 

I could try to be a release manager but I have almost no experience in publishing new releases, so it can be error prone. I published the release only once using Gradle to Sonatype. I think I will be able to publish a new release but can't guarantee that everything will be smoothly.

I have a JIRA account. My account id is: porunov

Possibly, I could be a reserve release manager in case everyone else will be busy and couldn't publish a new release?

I think it will be good if there would be several release managers in reserve. Maybe Florian also want to be a release manager?

Best regards,

Oleksandr

On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

--
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/ccs5WZ3KHsQ/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/a9aa52bd-5671-431b-868d-c749cc2519cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I actually had the same order in mind. I'm hoping to finish up the testing on my open service wrapper PR next week and then work on noarch rpm and Deb packages to add to the releases. If we all agree about adding the packages I'm a blocker anyways.

While I do have a direct channel to Jason I'll still try to ask the relevant questions in this thread or a new one so everyone can have access to the information.

Chris

On Thu, Apr 11, 2019, 3:00 AM Oleksandr Porunov <ale...@...> wrote:

Thank you Jason!

Waiting for your notes.

I also think that we should release 0.2.3 then 0.3.2 then 0.4.0 so that users wouldn't be confused which one is the latest and which one they should use.

I would volunteer to be a release manager for 0.3.2. Basically, it doesn't matter to me which release to take I just think that all 3 new members should take 1 release each so that we all had some experience with publishing new releases.

My thoughts are the next:

Chris could take 0.2.3 release and prepare it first. I assume he has some direct connection with you, so if he would have some problem with the release, you could help him because you already prepared 5 last releases.

Florian made the main work for 0.4.0 release (update tinkerpop to 3.4.x, support cql for olap), so I assume he could be a release manager for this version.

I could be in the middle and take 0.3.2 release.

Chris, Florian, what do you think about such scheme? Chris - 0.2.3, Me - 0.3.2, Florian - 0.4.0.

I am OK with another order as well if someone wants to propose another order.

On Wednesday, April 10, 2019 at 5:49:35 PM UTC+3, Jason Plurad wrote:

All three have been added to the JanusGraph org https://issues.sonatype.org/browse/OSSRH-47679

Splitting up the release management duties sounds good. Do we have volunteer release managers for each release? The biggest chore of course is finalizing the release content and pushing those PRs to completion. I will get a PR submitted this week with my notes for the mechanics of the release process.

I don't think we need to coordinate a single day release for the different branches. The main thing would be to stress which one is actually the most current release, since GitHub will flag the last published as the latest.

On Thursday, April 4, 2019 at 7:42:01 PM UTC-4, Chris Hupman wrote:

If the plan is to split it up I'm more than willing to take one of the releases. My username is chupman.

On Thursday, April 4, 2019 at 1:31:01 AM UTC-7, Florian Hockmann wrote:

I could do the next line of releases. But if someone else wants to, then feel free to do so.

Jason: Would you say that it makes sense for a single committer to do all three releases or could it make sense to split this up so that one takes care of 0.2.3, one of 0.3.2 and one of 0.4.0? The release process sounds quite time consuming, especially if one person does all three releases.

I think it makes sense in general to have multiple committers being able to perform releases. So it would be good if you could create an issue to give us the necessary permissions. Maybe wait a few days in case other committers are also interested in being able to do releases.

My account id is: florianhockmann

Am Mittwoch, 3. April 2019 18:54:13 UTC+2 schrieb Oleksandr Porunov:

Hello Jason,

Thank you for your response. 

I could try to be a release manager but I have almost no experience in publishing new releases, so it can be error prone. I published the release only once using Gradle to Sonatype. I think I will be able to publish a new release but can't guarantee that everything will be smoothly.

I have a JIRA account. My account id is: porunov

Possibly, I could be a reserve release manager in case everyone else will be busy and couldn't publish a new release?

I think it will be good if there would be several release managers in reserve. Maybe Florian also want to be a release manager?

Best regards,

Oleksandr

On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

--
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/ccs5WZ3KHsQ/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/a9aa52bd-5671-431b-868d-c749cc2519cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

All three have been added to the JanusGraph org https://issues.sonatype.org/browse/OSSRH-47679

Splitting up the release management duties sounds good. Do we have volunteer release managers for each release? The biggest chore of course is finalizing the release content and pushing those PRs to completion. I will get a PR submitted this week with my notes for the mechanics of the release process.

I don't think we need to coordinate a single day release for the different branches. The main thing would be to stress which one is actually the most current release, since GitHub will flag the last published as the latest.

On Thursday, April 4, 2019 at 7:42:01 PM UTC-4, Chris Hupman wrote:

If the plan is to split it up I'm more than willing to take one of the releases. My username is chupman.

On Thursday, April 4, 2019 at 1:31:01 AM UTC-7, Florian Hockmann wrote:

I could do the next line of releases. But if someone else wants to, then feel free to do so.

Jason: Would you say that it makes sense for a single committer to do all three releases or could it make sense to split this up so that one takes care of 0.2.3, one of 0.3.2 and one of 0.4.0? The release process sounds quite time consuming, especially if one person does all three releases.

I think it makes sense in general to have multiple committers being able to perform releases. So it would be good if you could create an issue to give us the necessary permissions. Maybe wait a few days in case other committers are also interested in being able to do releases.

My account id is: florianhockmann

Am Mittwoch, 3. April 2019 18:54:13 UTC+2 schrieb Oleksandr Porunov:

Hello Jason,

Thank you for your response. 

I could try to be a release manager but I have almost no experience in publishing new releases, so it can be error prone. I published the release only once using Gradle to Sonatype. I think I will be able to publish a new release but can't guarantee that everything will be smoothly.

I have a JIRA account. My account id is: porunov

Possibly, I could be a reserve release manager in case everyone else will be busy and couldn't publish a new release?

I think it will be good if there would be several release managers in reserve. Maybe Florian also want to be a release manager?

Best regards,

Oleksandr

On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

If the plan is to split it up I'm more than willing to take one of the releases. My username is chupman.

On Thursday, April 4, 2019 at 1:31:01 AM UTC-7, Florian Hockmann wrote:

I could do the next line of releases. But if someone else wants to, then feel free to do so.

Jason: Would you say that it makes sense for a single committer to do all three releases or could it make sense to split this up so that one takes care of 0.2.3, one of 0.3.2 and one of 0.4.0? The release process sounds quite time consuming, especially if one person does all three releases.

I think it makes sense in general to have multiple committers being able to perform releases. So it would be good if you could create an issue to give us the necessary permissions. Maybe wait a few days in case other committers are also interested in being able to do releases.

My account id is: florianhockmann

Am Mittwoch, 3. April 2019 18:54:13 UTC+2 schrieb Oleksandr Porunov:

Hello Jason,

Thank you for your response. 

I could try to be a release manager but I have almost no experience in publishing new releases, so it can be error prone. I published the release only once using Gradle to Sonatype. I think I will be able to publish a new release but can't guarantee that everything will be smoothly.

I have a JIRA account. My account id is: porunov

Possibly, I could be a reserve release manager in case everyone else will be busy and couldn't publish a new release?

I think it will be good if there would be several release managers in reserve. Maybe Florian also want to be a release manager?

Best regards,

Oleksandr

On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

I could do the next line of releases. But if someone else wants to, then feel free to do so.

Jason: Would you say that it makes sense for a single committer to do all three releases or could it make sense to split this up so that one takes care of 0.2.3, one of 0.3.2 and one of 0.4.0? The release process sounds quite time consuming, especially if one person does all three releases.

I think it makes sense in general to have multiple committers being able to perform releases. So it would be good if you could create an issue to give us the necessary permissions. Maybe wait a few days in case other committers are also interested in being able to do releases.

My account id is: florianhockmann

Am Mittwoch, 3. April 2019 18:54:13 UTC+2 schrieb Oleksandr Porunov:

Hello Jason,

Thank you for your response. 

I could try to be a release manager but I have almost no experience in publishing new releases, so it can be error prone. I published the release only once using Gradle to Sonatype. I think I will be able to publish a new release but can't guarantee that everything will be smoothly.

I have a JIRA account. My account id is: porunov

Possibly, I could be a reserve release manager in case everyone else will be busy and couldn't publish a new release?

I think it will be good if there would be several release managers in reserve. Maybe Florian also want to be a release manager?

Best regards,

Oleksandr

On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

Hello Jason,

Thank you for your response. 

I could try to be a release manager but I have almost no experience in publishing new releases, so it can be error prone. I published the release only once using Gradle to Sonatype. I think I will be able to publish a new release but can't guarantee that everything will be smoothly.

I have a JIRA account. My account id is: porunov

Possibly, I could be a reserve release manager in case everyone else will be busy and couldn't publish a new release?

I think it will be good if there would be several release managers in reserve. Maybe Florian also want to be a release manager?

Best regards,

Oleksandr

On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

Releases are done on Sonatype OSS. For reference, here is original conversation and the original ticket for JanusGraph.

If a committer is interested in stepping up to be a release manager, you can create a JIRA account here. Once I have your account id, I (or others associated with the org) can open a ticket to get you added to the JanusGraph org.

Clearly there is still more to flesh out on release process, but they largely follow steps similar to Apache TinkerPop since there's a shared history between TinkerPop and Titan.

-- Jason

On Thursday, March 14, 2019 at 7:00:23 AM UTC-4, Florian Hockmann wrote:

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph?

Good point of course :D No, I don't have any credentials.

 

That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

But that has nothing to do with when we'll release 0.2.3. We should simply not target 0.2 any more with any new PRs now, irrespective of whether we have released 0.2.3 or not. That was already in my first post here:

My suggestion here is that we don't target 0.2 for any new pull requests

Am Donnerstag, 14. März 2019 11:37:02 UTC+1 schrieb Oleksandr Porunov:

Florian,

Do you have keys to publish new releases? Do you know which Nexus is used by JanusGraph? I believe it is Sonatype but I can't be sure. If you don't have keys then we definitely need help from those who has necessary keys. If you have keys than I can try to help with publishing new release (I did it only once with Sonatype so I need to research the flow once again). Of course, if someone who has more experience can help it would be awesome.  

I think that we can wait for those PRs to be merged and then start preparation for 0.2.3 release. I think it is better to release 0.2.3 shortly because most bugfix PRs are required to have tests. 0.2 branch has JUnit 4 and 0.3 branch has JUnit 5, so almost each merge from 0.2 to 0.3 should be changed to rewrite test from JUnit 4 to JUnit 5 and fix conflicts. That is why I think it is better to close 0.2 branch shortly to avoid those additional steps.

On Thursday, March 14, 2019 at 11:31:05 AM UTC+2, Florian Hockmann wrote:

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?