[DISCUSS] 0.1.0 Release Prep

[Ted Wilmes]

Hello,

I have created a release branch (jg01) we can use for 0.1.0 prep.  I think at this point we're ready to discuss what will go into 0.1.0.  Open issues

tagged for the 0.1.0 milestone can be seen at https://github.com/JanusGraph/janusgraph/milestone/1.

Should the TinkerPop upgrade issue #41 be closed out at this point Sjudeng since you guys completed the 3.2.3 upgrade?  I think 

#73 Titan Compatibility can probably be closed as the related PR has been merged.  That leaves 6 more outstanding issues.  Which of these

would you all like to see included for sure versus what could be pushed?  Are there any additional issues that are not tagged for 0.1.0 that

should be?  I could see #171 being one possibility.

Thanks,

Ted

[sjudeng]

Thanks for getting the ball rolling on this. Below are my recommendations based on 0.1.0 being scoped as an initial compatibility release to enable the easiest possible Titan->JanusGraph transition. In this case no new features are really required.

#41 TinkerPop 3.2 upgrade (status: closed)
- I closed this issue assuming it's reasonable to tie it to the upgrade to 3.2.3 and opened a new issue for the update to 3.2.4, which in my opinion isn't a blocker for the 0.1.0 release. It is worth noting though that JanusGraph TinkerPop tests do require a TinkerPop commit that is not in 3.2.3. I recommend making a temporary note of the workaround steps for this in documentation (e.g. BUILDING.md), which could be removed after updating to 3.2.4.

#74 Automated testing in Travis (remove from 0.1.0 milestone)
- I think it's important that all tests (including TinkerPop tests) are run on the release candidate, but I don't think it's necessary for this to be fully automated through Travis.

#120 Improve documentation of ids.num-partitions
- I can go either way on this one.

#128 Dependency license check in Travis (remove from 0.1.0 milestone)
- Like testing this check could be manual for 0.1.0.

#132 Non-permissive licenses in dependencies (remove from 0.1.0 milestone)
- From a user perspective these dependencies have been there since Titan and have not been added by JanusGraph. The only issue would be if there are additional restrictions on JanusGraph as a Linux Foundation project.

#133 Mark JTS optional in janusgraph-solr (remove from 0.1.0 milestone)
- Same as #132 above.

#147 Support custom ids (remove from 0.1.0 milestone)
- I don't think we're close on this and it's definitely a new feature (or a long outstanding bug?)

#171 Test failures in janusgraph-berkeleyje (add to 0.1.0 milestone)
- I think all tests need to pass for a release.

[Ted Wilmes]

Nice summary and I'm in agreement with the ones you've marked to remove from the milestone.

In addition, I think #120 could be pushed.  These are all important, but I do not think critical, for the 

first release.  I'm also in agreement that #171 should be added.  I saw your note on that and I'll take

a look at it too.

--Ted

[Florian Hockmann]

I agree with your assessment of the issues for the first release which basically comes down to the conclusion that only #171 has to be resolved for the release if I didn't miss anything. (Assuming that #120 isn't seen as a show stopper as the documentation was already unclear for Titan in that regard.)

Therefore I hope that #171 can be quickly resolved so that we have a first official release. (Unfortunately I cannot provide any input there as I never worked with BerkleyDB.) But in case that #171 takes longer to be resolved I would highly appreciate another snapshot release as the current release branch probably resembles already the final release for everything apart for the BerkleyDB storage backend. The current snapshot is probably not an option for most people to upgrade from Titan as it is not backwards compatible when using Cassandra as the storage backend (due to missing changes from #80).

[Ted Wilmes]

Thanks for weighing in Florian.  I went ahead and created a new 0.2.0 milestone and moved the non-essentials for 0.1.0 that we identified over.  That leaves #102 (version compatibility matrix) and #171.  I realize we may end up having minor releases (0.1.1, etc.) but figured for now I'd just move the carryovers into 0.2.0 and we can readjust later as needed.

Thanks,

Ted

[sjudeng]

A PR has been submitted to resolve #171. With this update all core and TinkerPop tests are passing on all modules in the jg01 branch.

I propose adding #182 (Travis CI on release branch) and #184 (release documentation updates) to the milestone. Both these issues are associated with open PRs.

I also recommend we add relevant closed issues/PRs to the 0.1.0 milestone. The changelog will include a reference to the milestone GitHub page so I think it'll useful if this provides as complete a picture as possible on updates included in the release. Minor updates (documentation/etc.) are probably not necessary to include but others (HBase/BerkeleyJE upgrades, Google Big Table support, etc.) should probably be added.

[Misha Brukman]

Sorry I'm late to the party, but can we change the branch name strategy? Presumably, these branch names will be long-lived (we will have patch releases) and folks will want to see these in the future, so I'd like to make sure they're readable, unique, and meaningful.

I'd like to propose the following:

• branch name: 0.1.x (literally), 0.2.x, etc. — the 'x' is the wildcard since the branch will move forward; no need for a "jg" prefix (we know what the project name is), and we should include the dots to separate major vs. minor vs. patch (see below as to why)
• release tags: 0.1.0, 0.1.1, etc. — specific versions, no wild cards, these are meant to be fixed-in-place
• release candidates / snapshots: 0.1.0-rc1, 0.1.0-rc2 — I know I earlier proposed 0.1.0-SNAPSHOT-<date> and I'm retracting it, having seen that this is what several Apache projects are ding, and I find it's more meaningful, simpler, and shorter

These will be directly visible in the URLs, e.g., https://github.com/janusgraph/janusgraph/tree/0.1.0/... as well as when we suggest a user check out a specific tag or branch, it's in the command line. It's much easier if this is meaningful, easily readable version id. Using a pattern such as "jg01" means we'll use "jg10" for 1.0, but what will 10.0 use? "jg10" vs. "jg100" will be very confusing.

Or, if we go to 0.11 (hypothetically), that would be "jg011" but what if we also have 0.1.1? That would also be "jg011" using this model.

Thoughts?

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jerry He]

Thanks for the work, Ted, sjudeng.

I am good with what you suggested, Misha.

0.1.x (literally), 0.2.x

There is no need to have the 'x' though.  0.1 is the minor release branch line and will move forward.

Thanks.

Jerry

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.

[Misha Brukman]

On Sun, Apr 2, 2017 at 12:26 AM, Jerry He <jerr...@gmail.com> wrote:

I am good with what you suggested, Misha.

0.1.x (literally), 0.2.x

There is no need to have the 'x' though.  0.1 is the minor release branch line and will move forward.

I think we need to explicitly differentiate movable pointers (release branches) vs. static pointers (specific version tags).

One proposal is what I shared earlier: 0.1.x (branches) and 0.1.1 (version tags). My concern is that 0.1 (branch) vs. 0.1.0 (release tag) is insufficiently different as to be confusing which is movable vs. static.

Here are some alternatives from a couple Apache projects:

• Storm uses "0.1.0" (branch) and "v0.1.0" (tag) — essentially what Jerry is proposing (with a "v" prefix for version tags)
• Zeppelin uses "branch-0.5" (branch) and "v0.5.1" (tag) — verbose
  
• Toree (incubating) uses "0.1.x" and "v0.1.2" (tag) — essentially what I proposed
• HBase uses "0.18" (branch) and "release-0.1" or "rel/0.1" (tags) — verbose
  
• Cassandra uses "cassandra-0.1" for both branches and tags — seems confusing

Taking Jerry's suggestion and Storm's approach of differentiating the branches vs. tags, we can do the following:

• branches: 0.1, 0.2, etc. — no wildcard
• version tags: v0.1.0 — 'v' prefix
• release candidates: v0.1-rc1 — 'v' prefix, 'rc#' suffix

Any objections?

Misha

[sjudeng]

This sounds good to me. Would the release candidate be 0.1.0-rc1 instead of 0.1-rc1?

Another related question is whether or not to target release features on the release branch or master. I've been targeting 0.1.0 features on the release branch with the understanding that we can and should be regularly merging the release branch into master. This model of merging relevant features into release branches and then merging release branches into master is what TinkerPop does (see merge commits on https://github.com/apache/tinkerpop/commits/master).

[Jerry He]

+1 on the new proposal.

Thanks.

Jerry

[sjudeng]

Are there any other issues not in the milestone we need to add for 0.1.0? I can see #132 (onc/rpc dependency exclusion).

The branch as it is now (with #179 merged) is fully tested including core and TinkerPop tests. All other issues currently in the milestone are documentation updates, which aren't a worry in terms of stability/testing. Also I don't think #132 would impact testing (Jason, are there any metrics tests that might be affected?). If we can refrain from adding any more code updates then I think we can move out without further (unit) testing on the 0.1.0 release pending merge of #179 (and maybe #132) and review/merge of the documentation updates (#102, #177, #184).

Ted I assume you'll be the RM on the 0.1.0 release?

[Ted Wilmes]

#179 looks good to me and now has 2 +1's.  I'll merge it.  I'd been slow playing the RM thing...but I'll give it a shot barring anyone else jumping up enthusiastically requesting the position.  I would not be offended :)

So branch-wise, at this point, consensus is jg01 should be changed to 0.1?

Thanks,

Ted

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/YLnWWeNi0Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.

[Jason Plurad]

@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

[sjudeng]

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.

[sjudeng]

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.

[Henry Saputra]

@jason But should not be a blocker for 0.1 release I suppose ?

[sjudeng]

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.

[Ted Wilmes]

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...@gmail.com> wrote:

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.

--

[Ted Wilmes]

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

[Jason Plurad]

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:

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:

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

[sjudeng]

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.

[Ted Wilmes]

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...@gmail.com> wrote:

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.

--

[Ted Wilmes]

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

[sjudeng]

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.

[Misha Brukman]

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:

• commit the change s/0.1.0-SNAPSHOT/0.1.0/ to pom.xml files
• build the release
• commit the change s/0.1.0/0.1.1-SNAPSHOT/ to pom.xml files, so that any other changes on the branch, when built, automatically increment the version number

--

You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.

[Ted Wilmes]

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

[P. Taylor Goetz]

+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.

Misha

-Taylor

[P. Taylor Goetz]

On Apr 10, 2017, at 6:42 PM, 'Misha Brukman' via JanusGraph developer list <janusgr...@googlegroups.com> wrote:

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:

• commit the change s/0.1.0-SNAPSHOT/0.1.0/ to pom.xml files
• build the release
• commit the change s/0.1.0/0.1.1-SNAPSHOT/ to pom.xml files, so that any other changes on the branch, when built, automatically increment the version number

If we use the Maven release plugin, the version increment and “SNAPSHOT” removal will happen automatically.

-Taylor

On Mon, Apr 10, 2017 at 10:49 AM, Ted Wilmes <twi...@gmail.com> wrote:

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:

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...@gmail.com> wrote:

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.

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/YLnWWeNi0Ug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.

[Alexander Patrikalakis]

I joined the bandwagon late here, but for JTS and RPC packages, should we not include instructions to install them on gremlin shell?

Alex

[Ted Wilmes]

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...@gmail.com> wrote:

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]

+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

You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.

[Ted Wilmes]

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

To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.