[DISCUSS] 0.1.0 Release Prep


Ted Wilmes <twi...@...>
 

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 <sju...@...>
 

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 <twi...@...>
 

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


On Sunday, March 26, 2017 at 12:31:51 PM UTC-5, sjudeng wrote:
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.


Florian Hockmann <f...@...>
 

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

Am Sonntag, 26. März 2017 21:09:06 UTC+2 schrieb 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

On Sunday, March 26, 2017 at 12:31:51 PM UTC-5, sjudeng wrote:
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 <twi...@...>
 

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

On Thursday, March 30, 2017 at 9:27:50 AM UTC-7, Florian Hockmann wrote:
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).

Am Sonntag, 26. März 2017 21:09:06 UTC+2 schrieb 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

On Sunday, March 26, 2017 at 12:31:51 PM UTC-5, sjudeng wrote:
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.


sjudeng <sju...@...>
 

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 <mbru...@...>
 

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?

On Sun, Mar 26, 2017 at 12:11 PM, Ted Wilmes <twi...@...> wrote:
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


--
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 <jerr...@...>
 

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


On Saturday, April 1, 2017 at 8:59:49 PM UTC-7, Misha Brukman wrote:
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?

On Sun, Mar 26, 2017 at 12:11 PM, Ted Wilmes <t...@...> wrote:
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


--
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.
For more options, visit https://groups.google.com/d/optout.


Misha Brukman <mbru...@...>
 

On Sun, Apr 2, 2017 at 12:26 AM, Jerry He <jerr...@...> 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 <sju...@...>
 

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 <jerr...@...>
 

+1 on the new proposal.

Thanks.

Jerry

On Saturday, April 1, 2017 at 9:48:41 PM UTC-7, Misha Brukman wrote:
On Sun, Apr 2, 2017 at 12:26 AM, Jerry He <je...@...> 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 <sju...@...>
 

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 <twi...@...>
 

#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

On Mon, Apr 3, 2017 at 9:11 AM, sjudeng <sju...@...> wrote:
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?

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


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


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.


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.


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


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.


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

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


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

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