I’d like to start a discussion to flesh out a list of tasks necessary to make an initial release. Having a downloadable binary release and associated maven artifacts, IMO would help in terms of expanding the community by allowing potential users “kick the tires” of JanusGraph and get and idea of what’s required to migrate off of TitanDB.
From a process perspective, we should figure out how releases are planned and executed. In Apache projects, that typically falls to the Release Manager. That role typically rotates among commiters, and any committer is free to propose a release at any time. The process typically starts with a DISCUSS thread where the community discusses what features, bug fixes, etc. should to into the release, and deciding who will act as release manager for that release. Once the release is ready to be cut, the release manager builds the source release, binary release, and stages the Maven artifacts in Nexus. The next step is to start a VOTE thread to approve the release (the VOTE message contains links to all release artifacts: source/binary archives, associated checksums and signatures, and links to the Nexus staging repository. For the vote to pass, it requires a minimum of 3 positive votes, and more positive than negative votes. If the vote passes, the release artifacts are made available for download, and the Maven artifacts released from Nexus.The Apache release policy can be found here: http://www.apache.org/legal/release-policy.htmlI that a process we would like to adopt?
From an operational perspective, I can think of a few things:Any potential release managers would need a Nexus account. I already have one, so I can help facilitate the creation of the JanusGraph organization in Nexus (presumably using the “org.janusgraph” maven group ID). I would just need JIRA usernames for everyone. (You can create a JIRA account here: https://issues.sonatype.org/secure/Dashboard.jspa) I would want to do this in one fell swoop because the process requires human review and can take up to 48 hours.
Where would we host the downloads? The janusgraph.org website is in git, but I’m not sure we would want to store potentially big binaries there.
In terms of technical issues that should be resolved for the first release, do we want to list them out in this thread, use a GitHub issue label, or something else?
--
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.
On Mar 9, 2017, at 12:00 PM, sjudeng <sju...@gmail.com> wrote:
Let me know if this should be moved to another thread but is there any interest in scoping down the initial JanusGraph release to just be a "compatibility" release? There has been concern raised in discussions (for example here) that some users on production Titan systems would benefit from an initial release that has no breaking changes, especially to core storage, indexing and compute system components. There are already potentially breaking changes in master such as the TinkerPop update and others are in work.
Beyond mitigating concerns regarding having an initially easy migration step from Titan to JanusGraph, pursing a release branch without the additional features and dependency updates currently in work would allow for a relatively more rapid (and hopefully more stable) initial JanusGraph release. Any feedback on inevitable compatibility issues could then be addressed to the benefit of the subsequent JanusGraph release.
--
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.
The TinkerPop update is relevant because it would require production users of OLAP capabilities to upgrade their compute clusters (e.g. from Spark 1.2 to Spark 1.6).
--
The TinkerPop update is relevant because it would require production users of OLAP capabilities to upgrade their compute clusters (e.g. from Spark 1.2 to Spark 1.6).
--
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/8jkMnkKzmC0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
--
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.