Date
1 - 20 of 33
[DISCUSS] 0.1.0 Release Prep
|
Ted Wilmes <twi...@...>
I'm going to go ahead and start the vote process and we can work through this over in the vote thread. Thanks for all the help everyone. Thanks, Ted On Tuesday, April 11, 2017 at 7:08:08 PM UTC-5, P. Taylor Goetz wrote:
|
|
|
|
"P. Taylor Goetz" <ptg...@...>
+1 for continuing with the RC. Even if it fails it's a good exercise. I'm excited for the first release. Thanks Ted for stepping up as the first RM. -Taylor On Apr 11, 2017, at 6:51 PM, Ted Wilmes <twi...@...> wrote:
|
|
|
|
Ted Wilmes <twi...@...>
I'm about to send out the vote email. If you're okay with it, I'd still like to kick off the vote even if we end up scrapping this candidate and cutting a new one with the new additions. I'm thinking there is a high chance of at least a little churn on this since it's our first release. Just let me know if you think that approach makes sense and I'll start the vote and we can bring this up on the vote thread. Thanks, Ted On Tue, Apr 11, 2017 at 5:44 PM, Alexander Patrikalakis <amcpatr...@...> wrote: I joined the bandwagon late here, but for JTS and RPC packages, should we not include instructions to install them on gremlin shell? |
|
|
|
Alexander Patrikalakis <amcpatr...@...>
I joined the bandwagon late here, but for JTS and RPC packages, should we not include instructions to install them on gremlin shell?
Alex |
|
|
|
"P. Taylor Goetz" <ptg...@...>
If we use the Maven release plugin, the version increment and “SNAPSHOT” removal will happen automatically. -Taylor
|
|
|
|
"P. Taylor Goetz" <ptg...@...>
+1 The branch/version naming convention we use in Apache Storm has worked out well for us. The “v” prefix is used to make it easy to differentiate between tags and branches. As @sjudeng alluded to later in the thread, for release candidates I would recommend using the full 3 digit version number (i.e. "0.1.0-rc1”). Also, since tags are mutable and can change over the course of the release candidate cycle, we typically use the commit SHA instead of the tag in identifying the precise state of the current RC when sending out VOTE emails.
|
|
|
|
Ted Wilmes <twi...@...>
Yes, my plan was to do that as part of the release process, CTR'ing those changes before I released the artifacts for vote. As far as release date goes, for TinkerPop, we set the release date as the same as the start of the vote so if the JanusGraph vote were to start this Wednesday, it would be April 12. I like doing that because if we extend the vote for some reason, but do not need to rebuild any artifacts, we're good to go and don't change it again. This has worked well in the past but I wanted to see if that was okay with folks? Barring any delays, I'm looking to have things ready so that we can start the vote either tomorrow or Wednesday. Thanks, Ted On Mon, Apr 10, 2017 at 5:42 PM, Misha Brukman <mbru...@...> wrote:
|
|
|
|
Misha Brukman <mbru...@...>
Does the 0.1 branch need something akin to this commit but with s/0.1.0-SNAPSHOT/0.1.0/ ? Or is the idea is that this is done during the release process, but never committed to the repo? Would we want to do something like this:
On Mon, Apr 10, 2017 at 10:49 AM, Ted Wilmes <twi...@...> wrote:
|
|
|
|
sjudeng <sju...@...>
Sounds good. I confirmed again that the base tests are all passing on the 0.1 branch. This covered #186 and #189 (merged locally), which were added after the full suite was run. I didn't rerun the TinkerPop tests because I don't think these two commits would affect those. Note when preparing the release there's a "TBD" in both CHANGELOG.asc and docs/changelog.txt that you'll need to replace with the actual release date once that's known. |
|
|
|
Ted Wilmes <twi...@...>
With the merge of #189, we've finished everything tagged for 0.1.0. Unless there is anything unrepresented on that list, let's call the 0.1 branch frozen and I'll get started on the release process. Thanks, Ted On Friday, April 7, 2017 at 10:57:03 AM UTC-5, Ted Wilmes wrote:
|
|
|
|
Ted Wilmes <twi...@...>
One point of clarification on number 5. Right now, as you guys probably know, the docs are not actually included in the zip distribution. I think it would be nice to do that at some point, but was thinking for this round, including the "docs" would simply mean uploading the separate doc zip for review. Do you guys think that is sufficient or should we update the build so that the docs are copied into the dist.zip? Thanks, Ted On Fri, Apr 7, 2017 at 10:04 AM, sjudeng <sju...@...> wrote:
|
|
|
|
sjudeng <sju...@...>
Thanks for pushing forward on this. I think the tests are good. The only updates since tests were run were making ONC/RPC and JTS dependencies optional. But I can also rerun the test suite while you work through the other steps and they should complete in time for the vote. |
|
|
|
Jason Plurad <plu...@...>
This sounds great Ted. +1 on on the 0.1.0-rc2 tag. There's a fair chance something might go wrong, seeing that this is the first ever release. And if not, there's no problem if rc2 and 0.1.0 point at the same hash. Publishing the docs with the artifacts would be great. On Friday, April 7, 2017 at 10:29:49 AM UTC-4, Ted Wilmes wrote:
|
|
|
|
Ted Wilmes <twi...@...>
I did a dry run of the release prep last night and wanted to run the process by you all to see if it makes sense. 1. When they're ready, merge the last 2 open PRs. 2. Code freeze on 0.1 branch (do we need one final round of full testing at this point?) 3. Tag 0.1 with 0.1.0-rc2 4. Generate release artifacts (docs and signed zip) and deploy to sonatype but leave as "staged". 5. I'll create a new github pre-release against the 0.1.0-rc2 tag and upload the artifacts along with my signature. Should these include the docs? 6. Commence vote on the release. 7. Barring any issues, after a successful vote, I'll tag 0.1 branch with 0.1.0 and create the official github release, uploading the 0.1.0 artifacts. 8. Officially deploy the generated 0.1.0 docs to the docs repo. 9. Announce release Does this approach make sense to you guys? I was debating skipping the 0.1.0-rc2 tag step, and go with 0.1.0 immediately but leave it in github "prerelease" to start but could go either way with that. For TinkerPop, we do not make that distinction with the release candidate but that's not to say we couldn't do that here. Thanks, Ted On Thursday, April 6, 2017 at 8:42:48 AM UTC-5, Ted Wilmes wrote:
|
|
|
|
Ted Wilmes <twi...@...>
Thanks for all the hard work on this Sjudeng. I've been reviewing the current release process and will formally get started once these last items are in. There will be some deviations from the currently documented process as we will not be hosting artifacts on s3, etc. I will be documenting these and we can role the updated process into the docs after the release. Thanks, Ted On Thu, Apr 6, 2017 at 7:51 AM, sjudeng <sju...@...> wrote:
|
|
|
|
sjudeng <sju...@...>
I added #133 back to the 0.1.0 milestone and created PR #189 to resolve it. It already has one approval so we just need one more for merge. The other two issues in the milestone are addressed by PRs #176 and #185. Both of these have requested changes that have been addressed, so once reviewers are able to acknowledge and approve those changes we'll be set. |
|
|
|
Henry Saputra <henry....@...>
@jason But should not be a blocker for 0.1 release I suppose ? On Tuesday, April 4, 2017 at 7:22:25 AM UTC-7, Jason Plurad wrote:
|
|
|
|
sjudeng <sju...@...>
Misha, Shouldn't there be a distinction between snapshot releases and release candidates? In general snapshot releases like the one out there now may not be fully stable and well tested or have all features agreed upon for a formal release. On the other hand I thought we'd have a 0.1.0-RC1 when we're ready to call a vote on the 0.1.0 release, so that would be more stable and well vetted. |
|
|
|
sjudeng <sju...@...>
The release branch has been renamed to 0.1 with relevant PRs retargeted. There's also an open PR to merge 0.1 into master. It would be nice if merging from release branches into master (or other release branches) didn't require the additional redundant review. I'll look at #133 unless someone else is already on it. |
|
|
|
Jason Plurad <plu...@...>
@sjudeng, no I didn't see any metrics tests that would be affected by #132. I'd like to see mitigation of the LGPL for the JTS dependency #133 go in also. I looked around at some other projects: Apache Ignite uses a Maven profile to handle it, and Elasticsearch marks it as optional. @Ted +1 on the branch rename jg01 -> 0.1 On Monday, April 3, 2017 at 10:11:44 AM UTC-4, sjudeng wrote:
|
|
|