Florian Hockmann <f...@...>
toggle quoted message
Show quoted text
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.
On Thu, Apr 11, 2019, 3:00 AM Oleksandr Porunov <ale...@...
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:
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:
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?
On Wednesday, April 3, 2019 at 7:05:13 PM UTC+3, Jason Plurad wrote:
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.
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:
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:
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.,
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.,
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:
- We start release preparations for 0.2.3 shortly and close the 0.2 branch afterwards.
- 0.3 only gets bug fixes from now on.
- 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.