Date   

Re: [VOTE] JanusGraph 0.2.2 release

Chris Hupman <chris...@...>
 

I ended up replacing that check with the concept of the graph.storage-version when I wrote the upgrade for 0.3.x. Either we can hard code 0.2.2 as allowed or we can back-port the upgrade functionality. 

It really comes down to how many more releases are we planning to have for 0.2.x.

I should be able to submit a fix for this Monday if no one else grabs it.

Chris 

On Fri, Oct 5, 2018 at 10:09 PM Jerry He <jerr...@...> wrote:
I was trying to do some testing:

JanusGraph 0.2.2 can not read graph from 0.2.1.

org.janusgraph.core.JanusGraphException: StorageBackend version is incompatible with current JanusGraph version: storage [0.2.1] vs. runtime [0.2.2]
        at org.janusgraph.graphdb.configuration.GraphDatabaseConfiguration.<init>(GraphDatabaseConfiguration.java:1434)

Jerry

On Fri, Oct 5, 2018 at 9:10 AM, Chris Hupman <chris...@...> wrote:
+1


On Tuesday, October 2, 2018 at 6:47:50 PM UTC-7, Jason Plurad wrote:
Hello,

We are happy to announce that JanusGraph 0.2.2 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.2

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.2/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To post to this group, send email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/26dca088-213e-4d14-a429-4e2b7a5bf6ef%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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/VB1lImR9jRg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgr...@....
To post to this group, send email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/CAHkeaHUW3wifZFdB9%2BH2Zo34XfObpWd6OAv52jS3F%3D4d-oOUkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [VOTE] JanusGraph 0.2.2 release

Jerry He <jerr...@...>
 

I was trying to do some testing:

JanusGraph 0.2.2 can not read graph from 0.2.1.

org.janusgraph.core.JanusGraphException: StorageBackend version is incompatible with current JanusGraph version: storage [0.2.1] vs. runtime [0.2.2]
        at org.janusgraph.graphdb.configuration.GraphDatabaseConfiguration.<init>(GraphDatabaseConfiguration.java:1434)

Jerry

On Fri, Oct 5, 2018 at 9:10 AM, Chris Hupman <chris...@...> wrote:
+1


On Tuesday, October 2, 2018 at 6:47:50 PM UTC-7, Jason Plurad wrote:
Hello,

We are happy to announce that JanusGraph 0.2.2 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.2

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.2/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
To post to this group, send email to janusgraph-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/26dca088-213e-4d14-a429-4e2b7a5bf6ef%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Re: [VOTE] JanusGraph 0.3.1 release

Chris Hupman <chris...@...>
 

+1


On Tuesday, October 2, 2018 at 6:48:31 PM UTC-7, Jason Plurad wrote:
Hello,

We are happy to announce that JanusGraph 0.3.1 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.3.1

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.3.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.3.1/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad


Re: [VOTE] JanusGraph 0.2.2 release

Chris Hupman <chris...@...>
 

+1


On Tuesday, October 2, 2018 at 6:47:50 PM UTC-7, Jason Plurad wrote:
Hello,

We are happy to announce that JanusGraph 0.2.2 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.2

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.2/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad


Re: [VOTE] JanusGraph 0.3.1 release

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

+1

On Tue, Oct 2, 2018 at 9:48 PM, Jason Plurad <plu...@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.3.1 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.3.1

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.3.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.3.1/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
To post to this group, send email to janusgraph-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/6c8d42ed-25e8-4e13-80fc-efea73f12353%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [VOTE] JanusGraph 0.2.2 release

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

+1

On Tue, Oct 2, 2018 at 9:47 PM, Jason Plurad <plu...@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.2.2 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.2

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.2/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
To post to this group, send email to janusgraph-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/249e798a-db26-49cf-9328-405178d759ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Individual Versioning decision for GLV libraries

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

Now, when a breaking change becomes necessary at some point in the future, we can still decide whether it's big enough to require maintaining 2 branches: I'm still not able to imagine the scenario where such a code breaking change will be introduced. Code breaking changes for library I don't visualize yet, but code changes for user of library can be possible if few syntax or class changes in future.

I just meant any breaking change which could also simply be that a new GraphSON version is used by default. It doesn't have to be a breaking code change in the library itself.

I didn't know that having major version 0 implies that API may change

That's simply part of SemVer (semantic versioning). It states:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

and users expect exactly that of a library that has a 0.y.z version. I think that makes sense for us.

Do you mean the end point API like the one used to connect to Server? Or few of syntax?

I mean anything that requires users to change their code. Your PR for example currently contains a JanusGraphClient that has a connect and a get_connection method. What if we want to use just one method that does both in the future? Or what if we decide to unify the APIs of the libraries for the different languages?
It's really hard to figure out a good API right from the start. So, it's good if we have the possibility to change the API in early versions without breaking users expectations. However, a version 1.y.z implies that the API is relatively stable.

Well isn't syntax probable to change if some conflicting or new feature comes in?

New features shouldn't require breaking changes usually. Adding something doesn't break existing code.

Am Donnerstag, 4. Oktober 2018 15:42:35 UTC+2 schrieb Debasish Kanhar:
Adding new features (which requires a minor version bump) doesn't hinder users from upgrading in any way. So, I don't see why we would still maintain an older version without this new feature.: This sounds good, and better plan for going forward.

Now, when a breaking change becomes necessary at some point in the future, we can still decide whether it's big enough to require maintaining 2 branches: I'm still not able to imagine the scenario where such a code breaking change will be introduced. Code breaking changes for library I don't visualize yet, but code changes for user of library can be possible if few syntax or class changes in future.

as long as you provide upgrade notes to notify users about syntax changes, they would be able to upgrade to the newer version or they can also choose to stick with the previous version despite being out of maintenance: This sounds like the way to go forward. Like for eg, in my upcoming release, I've changed the syntax of connecting to JanusGraph server. We can provide a upgrade notes, on what changes to code or user will be required, or else they can decide to stick to older version if they don't need the upgraded lib's features.

Then the only scenario I think where we might need to maintain 2 different versions will be either when JanusGraph's actively maintained versions contains more than 2 GraphSON versions (Like GSon 3 & 4) or when together 2 separate TinkerPop versions are supported (Though this later one might require less of maintenance)

I didn't know that having major version 0 implies that API may change. Do you mean the end point API like the one used to connect to Server? Or few of syntax? Well isn't syntax probable to change if some conflicting or new feature comes in? Like the way to connect to running instace of JanusGrpah server for example.


On Wednesday, 3 October 2018 16:44:12 UTC+5:30, Florian Hockmann wrote:
I also think that we should keep the number of maintained branches / versions as low as possible, ideally only 1 branch will be actively maintained. Adding new features (which requires a minor version bump) doesn't hinder users from upgrading in any way. So, I don't see why we would still maintain an older version without this new feature. Now, when a breaking change becomes necessary at some point in the future, we can still decide whether it's big enough to require maintaining 2 branches or whether it's so small that we can expect users to just upgrade to the new major version in which case we would only have to maintain that version.

But it seems as if we have reached consensus on using semantic versioning for the libraries. We just need to decide whether we want to start at version 1.0.0 or 0.0.1.
I would be ok with both versions, but I have a slight preference towards 0.0.1 as a major version of 0 implies that the API may change at any time which allows us to still make some general adjustments to the API.

Am Dienstag, 2. Oktober 2018 22:20:25 UTC+2 schrieb Jason Plurad:
> I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing.

I would think as long as the drivers are largely backwards compatible, you'd be able to keep it to 2 active branches. Adding new features like schema management or geoshapes wouldn't break the previous functionality. And even if there were breaking changes, as long as you provide upgrade notes to notify users about syntax changes, they would be able to upgrade to the newer version or they can also choose to stick with the previous version despite being out of maintenance.


On Tuesday, October 2, 2018 at 2:20:36 PM UTC-4, Debasish Kanhar wrote:
I meant it in following sense. We go forward with releasing first version which will be tagged as 1.0.0

Now, this would be our current set of features, and as and when bugs are found out, a new patch release will be planned. Lets say some bug fixes leads us to release 1.0.1, then 1.0.2, then 1.0.3 and so on. Thus no we have a line of releases corresponding to patch version which needs to be maintained. I would suggest here just maintaining the latest in line, i.e. if 1.0.2 is out, then 1.0.1 and 1.0.0 won't be activly maintained.

As for minor version bump, let us say that we added a new feature named Schema management. Since it is a huge feature in itself, everything won't be added in single go. Let us say, we release the feature "Schema Management" in between 1.0.2 and 1.0.3 releases. Since it is a new feature, the version which will be released corresponding to the feature will involve a bump in minor version. Since last stable patch release was 1.0.2, hence the new minor release will be tagged 1.1.0 and will include all patch fixes of 1.0.2.
Now, we have 2 separate stable releases, one is 1.1.0 and other will be 1.0.2. All the patches related to Schema management will go into 1.1.x series, i.e. new release named 1.1.1, 1.1.2, 1.1.3 and so on will be released. All patches for non schema library will go into 1.0.x series, i.e. 1.0.3, 1.0.4, 1.0.5 and so on will be released. At end of release, we now have 2 separate versions which need to be actively maintained. Latest in line of 1.0.x series and latest in line of 1.1.x series.

Once another feature is introduced which brings in bump in minor version, let us say new Geoshapes, we will move to 1.2.x series of versions with their corresponding Patch releases. 1.2.x series will contain the latest stable version of 1.1.x series and new features will be added on top of it. Once 1.2.x series are out, then we will stop actively maintaining 1.1.x series, and all corresponding Patch releases moves to 1.2.x series now.

As for huge code breaking changes, like TP version change of GraphSON change, we will just bump the major version number which would be in sync with latest in line of 1.x.y series and 1.0.x series.

Thus, at end of day, we are actively maintaining 3 versions parallely.

One would be latest in line of 1.0.x version, which would be the naked library with least features and their bugs fixed.
Second would be latest in line of 1.x.y version which contains the recent feature added, like either Schema management, GeoShapes etc along with their corresponding bugs fixed.
Third would be, though not required to actively maintain those will be those versions which had change in TP or GraphSON, so that when me merge the feature releases upstream (from patch and minor to major fix branch), we can easily check for conflicts, and will need to maintain only those where conflicts arise.

Let us consider 1.2.2 contains all the recent library with all new features like Schema and Geoshapes added. We will just need to bump TP version for new JanusGraph 0.4.0 and that goes into 2.0.0. All the bug fixes due to conflicts will go into 2.0.x line of releaes, while any new feature would require first creating those features in minor release for older stable TP, like 1.3.0 released, and then those changes are merged upstream into 2.0.0 to form 2.1.0 release. This way once a new feature is added, it gets automatically also added to older versions of library thus working with older version of JanusGraph too.

I hope I was clear on maintainability aspect too, but I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing.

Cheers


On Tuesday, 2 October 2018 18:39:49 UTC+5:30, Florian Hockmann wrote:
3. But if JanusGraph version is upgraded, we don't necessary need to upgrade the Client unless TinkerPop change happens.

The major version bump will be latest version or minor bump series and patch series + new dependency changes. (Eg: If JanusGraph 0.4.0 comes with TP 3.4, then due to code breaks, we will need to to bump Major version number. Considering that latest release of minor version is 1.1.1 and or patch release is 1.0.2, then 2.0.0 will contain all features of 1.1.1 and 1.0.2 along with dependency changes)

I don't get what you mean with this. How can the latest minor version be 1.1.1? Minor version just means the second element of the version number which would be '2' in the version 1.2.3. My proposal was simply to employ semantic versioning. But you're right in general that an update of TinkerPop to 3.4.0 could break things for the client libraries and therefore require a major version bump instead of just a minor version bump.

In general, I can't quite follow what you propose regarding actively maintained branches. How is the versioning related to the number of branches we have to maintain?

Am Dienstag, 2. Oktober 2018 12:34:54 UTC+2 schrieb Debasish Kanhar:
Hi Florian,

Okay, thanks for pointing that out, and I do see few issues with my idea, as in inde[endently bumping major and minor versions of clients by itself without upgrade to JanusGraph is difficult.

At same time I like your idea a lot better but a few issues still remain which adds extra level of complexity and maintainabiliy.

Correct me if my understanding is wrong, (I'm in favour of starting version numbers from 1.0.0 as that seems lot cleaner ;-) )

1. 1.0.0 Supports JanusGraph 0.3.0
2. If Patch is released for same version, we simply bump minor version to 1.0.1.
3. But if JanusGraph version is upgraded, we don't necessary need to upgrade the Client unless TinkerPop change happens. Like JanusGraph 0.3.1 will still use TP 3.3.3 and hence clients of JG 0.3.0 will work with JG 0.3.1 also. So we don't need to release another version of client with bump in patch number just because to sync with bump in JanusGraph patch version upgrade.
4. If a new feature is released for client, let us say schema management, it leads to bump in minor version number, and will be in line with recent patch. i.e. 1.0.1 (Latest patch in line of 1.0) gets merged with recent bump of minor version, (i.e. 1.1.0 will have all features of 1.0.1 + the new feature being released) thus reducing number of versions to be maintained.
5. If any of JanusGraph versions brings in a major change like TinkerPop version change or GraphSON version change, or similar change which will break the library, then we bump the Major Version number. The major version bump will be latest version or minor bump series and patch series + new dependency changes. (Eg: If JanusGraph 0.4.0 comes with TP 3.4, then due to code breaks, we will need to to bump Major version number. Considering that latest release of minor version is 1.1.1 and or patch release is 1.0.2, then 2.0.0 will contain all features of 1.1.1 and 1.0.2 along with dependency changes)

The plus I see with this is, we will need to just actively maintain 2 branches, latest in line of minor and latest in line of patch releases. In this case, 1.1.1 and 1.0.2. Since TinkerPop version change doesn't require additional changes except changing the dependency, the latest in major release line will also be maintained, but requires less work to maintain, and hence helps in maintaing as many major version branches.

Also, if the major version change did bring any major breaking changes (like in case of GraphSON), then either a new version is released by bumping patch number of minor version depending on the type of new feature the bump brings in.

What do you think? A mix of both of our ideas I think :-D



On Monday, 1 October 2018 18:10:44 UTC+5:30, Florian Hockmann wrote:
Thanks for getting the discussion on this topic started!

One disadvantage I see with your proposal is that those version numbers imply semantic versioning but they prevent the libraries from making any changes except for patches independently of the main project as they have to wait for a version bump of JanusGraph's minor or major version before they can bump their minor or major version.

Therefore, I would like to propose that the libraries simply use semantic versioning. That would look like this:

1st release of JanusGraph-Python will be 0.0.1 and target JanusGraph 0.3.0.

The version number for the next release depends on the nature of the included changes:
  1. A patch release results in 0.0.2.
  2. Added functionality requires a minor version bump, so: 0.1.0.
  3. A breaking change bumps the major version number: 1.0.0. (Although versions pre 1.0.0 might still only bump the minor version and only go to 1.0.0 to convey a certain stability of the library.)
  4. Compatibility with a newer JanusGraph version bumps the equivalent version number: Supporting JanusGraph 0.4.0 would result in 0.1.0, whereas supporting JanusGraph 0.3.1 only results in 0.0.2.
The only downside I see with semantic versioning for the libraries is that they need to convey the supported JanusGraph version through another way, but that also seems to be necessary with your method as it's not clear just from a version number like 1.0.0 which JanusGraph version is supported. However, with pure semantic versioning we gain the increased flexibility we wanted to get with the independent versioning of those libraries.

What do you think?

Am Freitag, 28. September 2018 22:56:17 UTC+2 schrieb Debasish Kanhar:
Hi All,

A few days back, Florian had started a Discuss thread regarding how should we version the upcoming GLV libraries for Python and DotNet. After discussions and lazy consensus it felt like we should go forward with independent version numbers for the GLV libraries than the official JanusGraph.

Hence, coming back the main question then remains is even though independent how do we version the GLV libraries.

I've been following the following version semantics and would like to propose the same.

The GLV library will follow x.y.z version number where each are described as follows:
x: Corresponds to a particular JanusGraph major release version.
y: Corresponds to a particular JanusGraph minor release version
z: Corresponds to the path release for GLV library in itself.

For example, since we are starting to support begining JanusGraph 0.3.0, the following set of versions will be followed according to above proposed rule.

JanusGraph 0.3.0 : JanusGraph-Py 1.0.0
JanusGraph 0.3.0 : JanusGraph-Py 1.0.z [For all patches which are compatible with drivers for JanusGraph 0.3.0]

JanusGraph 0.3.1 : JanusGraph-Py 1.1.0 [Notice y change, because there was minor version change in JanusGraph]
JanusGraph 0.3.1 : JanusGraph-Py 1.1.z [For all patches for same JanusGraph version]

When JanusGraph bumps by Major version change like lets say 0.4.0,

JanusGraph 0.4.0 JanusGraph-Py 2.0.z
JanusGraph 0.4.1 JanusGraph-Py 2.1.z

And so on. The above rule helps in maintaining release plan for GLV libraries separately than JanusGraph in itself, and at the same time brings down a bit of commonality in bumps across major/minor version changes of JanusGraph and its Clients.

I'm still open to other ideas, so everyone, all suggestions are welcome.

Cheers
Debasish K


Re: [DISCUSS] Individual Versioning decision for GLV libraries

Debasish Kanhar <d.k...@...>
 

Adding new features (which requires a minor version bump) doesn't hinder users from upgrading in any way. So, I don't see why we would still maintain an older version without this new feature.: This sounds good, and better plan for going forward.

Now, when a breaking change becomes necessary at some point in the future, we can still decide whether it's big enough to require maintaining 2 branches: I'm still not able to imagine the scenario where such a code breaking change will be introduced. Code breaking changes for library I don't visualize yet, but code changes for user of library can be possible if few syntax or class changes in future.

as long as you provide upgrade notes to notify users about syntax changes, they would be able to upgrade to the newer version or they can also choose to stick with the previous version despite being out of maintenance: This sounds like the way to go forward. Like for eg, in my upcoming release, I've changed the syntax of connecting to JanusGraph server. We can provide a upgrade notes, on what changes to code or user will be required, or else they can decide to stick to older version if they don't need the upgraded lib's features.

Then the only scenario I think where we might need to maintain 2 different versions will be either when JanusGraph's actively maintained versions contains more than 2 GraphSON versions (Like GSon 3 & 4) or when together 2 separate TinkerPop versions are supported (Though this later one might require less of maintenance)

I didn't know that having major version 0 implies that API may change. Do you mean the end point API like the one used to connect to Server? Or few of syntax? Well isn't syntax probable to change if some conflicting or new feature comes in? Like the way to connect to running instace of JanusGrpah server for example.


On Wednesday, 3 October 2018 16:44:12 UTC+5:30, Florian Hockmann wrote:
I also think that we should keep the number of maintained branches / versions as low as possible, ideally only 1 branch will be actively maintained. Adding new features (which requires a minor version bump) doesn't hinder users from upgrading in any way. So, I don't see why we would still maintain an older version without this new feature. Now, when a breaking change becomes necessary at some point in the future, we can still decide whether it's big enough to require maintaining 2 branches or whether it's so small that we can expect users to just upgrade to the new major version in which case we would only have to maintain that version.

But it seems as if we have reached consensus on using semantic versioning for the libraries. We just need to decide whether we want to start at version 1.0.0 or 0.0.1.
I would be ok with both versions, but I have a slight preference towards 0.0.1 as a major version of 0 implies that the API may change at any time which allows us to still make some general adjustments to the API.

Am Dienstag, 2. Oktober 2018 22:20:25 UTC+2 schrieb Jason Plurad:
> I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing.

I would think as long as the drivers are largely backwards compatible, you'd be able to keep it to 2 active branches. Adding new features like schema management or geoshapes wouldn't break the previous functionality. And even if there were breaking changes, as long as you provide upgrade notes to notify users about syntax changes, they would be able to upgrade to the newer version or they can also choose to stick with the previous version despite being out of maintenance.


On Tuesday, October 2, 2018 at 2:20:36 PM UTC-4, Debasish Kanhar wrote:
I meant it in following sense. We go forward with releasing first version which will be tagged as 1.0.0

Now, this would be our current set of features, and as and when bugs are found out, a new patch release will be planned. Lets say some bug fixes leads us to release 1.0.1, then 1.0.2, then 1.0.3 and so on. Thus no we have a line of releases corresponding to patch version which needs to be maintained. I would suggest here just maintaining the latest in line, i.e. if 1.0.2 is out, then 1.0.1 and 1.0.0 won't be activly maintained.

As for minor version bump, let us say that we added a new feature named Schema management. Since it is a huge feature in itself, everything won't be added in single go. Let us say, we release the feature "Schema Management" in between 1.0.2 and 1.0.3 releases. Since it is a new feature, the version which will be released corresponding to the feature will involve a bump in minor version. Since last stable patch release was 1.0.2, hence the new minor release will be tagged 1.1.0 and will include all patch fixes of 1.0.2.
Now, we have 2 separate stable releases, one is 1.1.0 and other will be 1.0.2. All the patches related to Schema management will go into 1.1.x series, i.e. new release named 1.1.1, 1.1.2, 1.1.3 and so on will be released. All patches for non schema library will go into 1.0.x series, i.e. 1.0.3, 1.0.4, 1.0.5 and so on will be released. At end of release, we now have 2 separate versions which need to be actively maintained. Latest in line of 1.0.x series and latest in line of 1.1.x series.

Once another feature is introduced which brings in bump in minor version, let us say new Geoshapes, we will move to 1.2.x series of versions with their corresponding Patch releases. 1.2.x series will contain the latest stable version of 1.1.x series and new features will be added on top of it. Once 1.2.x series are out, then we will stop actively maintaining 1.1.x series, and all corresponding Patch releases moves to 1.2.x series now.

As for huge code breaking changes, like TP version change of GraphSON change, we will just bump the major version number which would be in sync with latest in line of 1.x.y series and 1.0.x series.

Thus, at end of day, we are actively maintaining 3 versions parallely.

One would be latest in line of 1.0.x version, which would be the naked library with least features and their bugs fixed.
Second would be latest in line of 1.x.y version which contains the recent feature added, like either Schema management, GeoShapes etc along with their corresponding bugs fixed.
Third would be, though not required to actively maintain those will be those versions which had change in TP or GraphSON, so that when me merge the feature releases upstream (from patch and minor to major fix branch), we can easily check for conflicts, and will need to maintain only those where conflicts arise.

Let us consider 1.2.2 contains all the recent library with all new features like Schema and Geoshapes added. We will just need to bump TP version for new JanusGraph 0.4.0 and that goes into 2.0.0. All the bug fixes due to conflicts will go into 2.0.x line of releaes, while any new feature would require first creating those features in minor release for older stable TP, like 1.3.0 released, and then those changes are merged upstream into 2.0.0 to form 2.1.0 release. This way once a new feature is added, it gets automatically also added to older versions of library thus working with older version of JanusGraph too.

I hope I was clear on maintainability aspect too, but I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing.

Cheers


On Tuesday, 2 October 2018 18:39:49 UTC+5:30, Florian Hockmann wrote:
3. But if JanusGraph version is upgraded, we don't necessary need to upgrade the Client unless TinkerPop change happens.

The major version bump will be latest version or minor bump series and patch series + new dependency changes. (Eg: If JanusGraph 0.4.0 comes with TP 3.4, then due to code breaks, we will need to to bump Major version number. Considering that latest release of minor version is 1.1.1 and or patch release is 1.0.2, then 2.0.0 will contain all features of 1.1.1 and 1.0.2 along with dependency changes)

I don't get what you mean with this. How can the latest minor version be 1.1.1? Minor version just means the second element of the version number which would be '2' in the version 1.2.3. My proposal was simply to employ semantic versioning. But you're right in general that an update of TinkerPop to 3.4.0 could break things for the client libraries and therefore require a major version bump instead of just a minor version bump.

In general, I can't quite follow what you propose regarding actively maintained branches. How is the versioning related to the number of branches we have to maintain?

Am Dienstag, 2. Oktober 2018 12:34:54 UTC+2 schrieb Debasish Kanhar:
Hi Florian,

Okay, thanks for pointing that out, and I do see few issues with my idea, as in inde[endently bumping major and minor versions of clients by itself without upgrade to JanusGraph is difficult.

At same time I like your idea a lot better but a few issues still remain which adds extra level of complexity and maintainabiliy.

Correct me if my understanding is wrong, (I'm in favour of starting version numbers from 1.0.0 as that seems lot cleaner ;-) )

1. 1.0.0 Supports JanusGraph 0.3.0
2. If Patch is released for same version, we simply bump minor version to 1.0.1.
3. But if JanusGraph version is upgraded, we don't necessary need to upgrade the Client unless TinkerPop change happens. Like JanusGraph 0.3.1 will still use TP 3.3.3 and hence clients of JG 0.3.0 will work with JG 0.3.1 also. So we don't need to release another version of client with bump in patch number just because to sync with bump in JanusGraph patch version upgrade.
4. If a new feature is released for client, let us say schema management, it leads to bump in minor version number, and will be in line with recent patch. i.e. 1.0.1 (Latest patch in line of 1.0) gets merged with recent bump of minor version, (i.e. 1.1.0 will have all features of 1.0.1 + the new feature being released) thus reducing number of versions to be maintained.
5. If any of JanusGraph versions brings in a major change like TinkerPop version change or GraphSON version change, or similar change which will break the library, then we bump the Major Version number. The major version bump will be latest version or minor bump series and patch series + new dependency changes. (Eg: If JanusGraph 0.4.0 comes with TP 3.4, then due to code breaks, we will need to to bump Major version number. Considering that latest release of minor version is 1.1.1 and or patch release is 1.0.2, then 2.0.0 will contain all features of 1.1.1 and 1.0.2 along with dependency changes)

The plus I see with this is, we will need to just actively maintain 2 branches, latest in line of minor and latest in line of patch releases. In this case, 1.1.1 and 1.0.2. Since TinkerPop version change doesn't require additional changes except changing the dependency, the latest in major release line will also be maintained, but requires less work to maintain, and hence helps in maintaing as many major version branches.

Also, if the major version change did bring any major breaking changes (like in case of GraphSON), then either a new version is released by bumping patch number of minor version depending on the type of new feature the bump brings in.

What do you think? A mix of both of our ideas I think :-D



On Monday, 1 October 2018 18:10:44 UTC+5:30, Florian Hockmann wrote:
Thanks for getting the discussion on this topic started!

One disadvantage I see with your proposal is that those version numbers imply semantic versioning but they prevent the libraries from making any changes except for patches independently of the main project as they have to wait for a version bump of JanusGraph's minor or major version before they can bump their minor or major version.

Therefore, I would like to propose that the libraries simply use semantic versioning. That would look like this:

1st release of JanusGraph-Python will be 0.0.1 and target JanusGraph 0.3.0.

The version number for the next release depends on the nature of the included changes:
  1. A patch release results in 0.0.2.
  2. Added functionality requires a minor version bump, so: 0.1.0.
  3. A breaking change bumps the major version number: 1.0.0. (Although versions pre 1.0.0 might still only bump the minor version and only go to 1.0.0 to convey a certain stability of the library.)
  4. Compatibility with a newer JanusGraph version bumps the equivalent version number: Supporting JanusGraph 0.4.0 would result in 0.1.0, whereas supporting JanusGraph 0.3.1 only results in 0.0.2.
The only downside I see with semantic versioning for the libraries is that they need to convey the supported JanusGraph version through another way, but that also seems to be necessary with your method as it's not clear just from a version number like 1.0.0 which JanusGraph version is supported. However, with pure semantic versioning we gain the increased flexibility we wanted to get with the independent versioning of those libraries.

What do you think?

Am Freitag, 28. September 2018 22:56:17 UTC+2 schrieb Debasish Kanhar:
Hi All,

A few days back, Florian had started a Discuss thread regarding how should we version the upcoming GLV libraries for Python and DotNet. After discussions and lazy consensus it felt like we should go forward with independent version numbers for the GLV libraries than the official JanusGraph.

Hence, coming back the main question then remains is even though independent how do we version the GLV libraries.

I've been following the following version semantics and would like to propose the same.

The GLV library will follow x.y.z version number where each are described as follows:
x: Corresponds to a particular JanusGraph major release version.
y: Corresponds to a particular JanusGraph minor release version
z: Corresponds to the path release for GLV library in itself.

For example, since we are starting to support begining JanusGraph 0.3.0, the following set of versions will be followed according to above proposed rule.

JanusGraph 0.3.0 : JanusGraph-Py 1.0.0
JanusGraph 0.3.0 : JanusGraph-Py 1.0.z [For all patches which are compatible with drivers for JanusGraph 0.3.0]

JanusGraph 0.3.1 : JanusGraph-Py 1.1.0 [Notice y change, because there was minor version change in JanusGraph]
JanusGraph 0.3.1 : JanusGraph-Py 1.1.z [For all patches for same JanusGraph version]

When JanusGraph bumps by Major version change like lets say 0.4.0,

JanusGraph 0.4.0 JanusGraph-Py 2.0.z
JanusGraph 0.4.1 JanusGraph-Py 2.1.z

And so on. The above rule helps in maintaining release plan for GLV libraries separately than JanusGraph in itself, and at the same time brings down a bit of commonality in bumps across major/minor version changes of JanusGraph and its Clients.

I'm still open to other ideas, so everyone, all suggestions are welcome.

Cheers
Debasish K


Question for JanusGraph experts about architecture and design for our application.

Bob van Luijt <b...@...>
 

Hi all,

We are working on a decentralized knowledge graph called Weaviate, and JanusGraph plays an important role in our software. We have a few people working on JanusGraph and they have some questions that they would like to ask a JG-expert (mostly related to architecture and design). These questions go a bit further than questions that would fit in one-off forum questions, therefore my request: Is there anybody in the community that would be open to discussing, brainstorming, and helping out with the questions that we have?

Many thanks in advance.

PS:
Needless to say but just to make sure, we also have some budget available if somebody is willing to invest some time and help us out with a brainstorm session.

PPS:
If this is not the right place to ask these questions, my apologies.


Re: [DISCUSS] Individual Versioning decision for GLV libraries

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

I also think that we should keep the number of maintained branches / versions as low as possible, ideally only 1 branch will be actively maintained. Adding new features (which requires a minor version bump) doesn't hinder users from upgrading in any way. So, I don't see why we would still maintain an older version without this new feature. Now, when a breaking change becomes necessary at some point in the future, we can still decide whether it's big enough to require maintaining 2 branches or whether it's so small that we can expect users to just upgrade to the new major version in which case we would only have to maintain that version.

But it seems as if we have reached consensus on using semantic versioning for the libraries. We just need to decide whether we want to start at version 1.0.0 or 0.0.1.
I would be ok with both versions, but I have a slight preference towards 0.0.1 as a major version of 0 implies that the API may change at any time which allows us to still make some general adjustments to the API.

Am Dienstag, 2. Oktober 2018 22:20:25 UTC+2 schrieb Jason Plurad:

> I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing.

I would think as long as the drivers are largely backwards compatible, you'd be able to keep it to 2 active branches. Adding new features like schema management or geoshapes wouldn't break the previous functionality. And even if there were breaking changes, as long as you provide upgrade notes to notify users about syntax changes, they would be able to upgrade to the newer version or they can also choose to stick with the previous version despite being out of maintenance.


On Tuesday, October 2, 2018 at 2:20:36 PM UTC-4, Debasish Kanhar wrote:
I meant it in following sense. We go forward with releasing first version which will be tagged as 1.0.0

Now, this would be our current set of features, and as and when bugs are found out, a new patch release will be planned. Lets say some bug fixes leads us to release 1.0.1, then 1.0.2, then 1.0.3 and so on. Thus no we have a line of releases corresponding to patch version which needs to be maintained. I would suggest here just maintaining the latest in line, i.e. if 1.0.2 is out, then 1.0.1 and 1.0.0 won't be activly maintained.

As for minor version bump, let us say that we added a new feature named Schema management. Since it is a huge feature in itself, everything won't be added in single go. Let us say, we release the feature "Schema Management" in between 1.0.2 and 1.0.3 releases. Since it is a new feature, the version which will be released corresponding to the feature will involve a bump in minor version. Since last stable patch release was 1.0.2, hence the new minor release will be tagged 1.1.0 and will include all patch fixes of 1.0.2.
Now, we have 2 separate stable releases, one is 1.1.0 and other will be 1.0.2. All the patches related to Schema management will go into 1.1.x series, i.e. new release named 1.1.1, 1.1.2, 1.1.3 and so on will be released. All patches for non schema library will go into 1.0.x series, i.e. 1.0.3, 1.0.4, 1.0.5 and so on will be released. At end of release, we now have 2 separate versions which need to be actively maintained. Latest in line of 1.0.x series and latest in line of 1.1.x series.

Once another feature is introduced which brings in bump in minor version, let us say new Geoshapes, we will move to 1.2.x series of versions with their corresponding Patch releases. 1.2.x series will contain the latest stable version of 1.1.x series and new features will be added on top of it. Once 1.2.x series are out, then we will stop actively maintaining 1.1.x series, and all corresponding Patch releases moves to 1.2.x series now.

As for huge code breaking changes, like TP version change of GraphSON change, we will just bump the major version number which would be in sync with latest in line of 1.x.y series and 1.0.x series.

Thus, at end of day, we are actively maintaining 3 versions parallely.

One would be latest in line of 1.0.x version, which would be the naked library with least features and their bugs fixed.
Second would be latest in line of 1.x.y version which contains the recent feature added, like either Schema management, GeoShapes etc along with their corresponding bugs fixed.
Third would be, though not required to actively maintain those will be those versions which had change in TP or GraphSON, so that when me merge the feature releases upstream (from patch and minor to major fix branch), we can easily check for conflicts, and will need to maintain only those where conflicts arise.

Let us consider 1.2.2 contains all the recent library with all new features like Schema and Geoshapes added. We will just need to bump TP version for new JanusGraph 0.4.0 and that goes into 2.0.0. All the bug fixes due to conflicts will go into 2.0.x line of releaes, while any new feature would require first creating those features in minor release for older stable TP, like 1.3.0 released, and then those changes are merged upstream into 2.0.0 to form 2.1.0 release. This way once a new feature is added, it gets automatically also added to older versions of library thus working with older version of JanusGraph too.

I hope I was clear on maintainability aspect too, but I'm still concerned about the number of releases which will need to be actively maintained as that keeps on increasing.

Cheers


On Tuesday, 2 October 2018 18:39:49 UTC+5:30, Florian Hockmann wrote:
3. But if JanusGraph version is upgraded, we don't necessary need to upgrade the Client unless TinkerPop change happens.

The major version bump will be latest version or minor bump series and patch series + new dependency changes. (Eg: If JanusGraph 0.4.0 comes with TP 3.4, then due to code breaks, we will need to to bump Major version number. Considering that latest release of minor version is 1.1.1 and or patch release is 1.0.2, then 2.0.0 will contain all features of 1.1.1 and 1.0.2 along with dependency changes)

I don't get what you mean with this. How can the latest minor version be 1.1.1? Minor version just means the second element of the version number which would be '2' in the version 1.2.3. My proposal was simply to employ semantic versioning. But you're right in general that an update of TinkerPop to 3.4.0 could break things for the client libraries and therefore require a major version bump instead of just a minor version bump.

In general, I can't quite follow what you propose regarding actively maintained branches. How is the versioning related to the number of branches we have to maintain?

Am Dienstag, 2. Oktober 2018 12:34:54 UTC+2 schrieb Debasish Kanhar:
Hi Florian,

Okay, thanks for pointing that out, and I do see few issues with my idea, as in inde[endently bumping major and minor versions of clients by itself without upgrade to JanusGraph is difficult.

At same time I like your idea a lot better but a few issues still remain which adds extra level of complexity and maintainabiliy.

Correct me if my understanding is wrong, (I'm in favour of starting version numbers from 1.0.0 as that seems lot cleaner ;-) )

1. 1.0.0 Supports JanusGraph 0.3.0
2. If Patch is released for same version, we simply bump minor version to 1.0.1.
3. But if JanusGraph version is upgraded, we don't necessary need to upgrade the Client unless TinkerPop change happens. Like JanusGraph 0.3.1 will still use TP 3.3.3 and hence clients of JG 0.3.0 will work with JG 0.3.1 also. So we don't need to release another version of client with bump in patch number just because to sync with bump in JanusGraph patch version upgrade.
4. If a new feature is released for client, let us say schema management, it leads to bump in minor version number, and will be in line with recent patch. i.e. 1.0.1 (Latest patch in line of 1.0) gets merged with recent bump of minor version, (i.e. 1.1.0 will have all features of 1.0.1 + the new feature being released) thus reducing number of versions to be maintained.
5. If any of JanusGraph versions brings in a major change like TinkerPop version change or GraphSON version change, or similar change which will break the library, then we bump the Major Version number. The major version bump will be latest version or minor bump series and patch series + new dependency changes. (Eg: If JanusGraph 0.4.0 comes with TP 3.4, then due to code breaks, we will need to to bump Major version number. Considering that latest release of minor version is 1.1.1 and or patch release is 1.0.2, then 2.0.0 will contain all features of 1.1.1 and 1.0.2 along with dependency changes)

The plus I see with this is, we will need to just actively maintain 2 branches, latest in line of minor and latest in line of patch releases. In this case, 1.1.1 and 1.0.2. Since TinkerPop version change doesn't require additional changes except changing the dependency, the latest in major release line will also be maintained, but requires less work to maintain, and hence helps in maintaing as many major version branches.

Also, if the major version change did bring any major breaking changes (like in case of GraphSON), then either a new version is released by bumping patch number of minor version depending on the type of new feature the bump brings in.

What do you think? A mix of both of our ideas I think :-D



On Monday, 1 October 2018 18:10:44 UTC+5:30, Florian Hockmann wrote:
Thanks for getting the discussion on this topic started!

One disadvantage I see with your proposal is that those version numbers imply semantic versioning but they prevent the libraries from making any changes except for patches independently of the main project as they have to wait for a version bump of JanusGraph's minor or major version before they can bump their minor or major version.

Therefore, I would like to propose that the libraries simply use semantic versioning. That would look like this:

1st release of JanusGraph-Python will be 0.0.1 and target JanusGraph 0.3.0.

The version number for the next release depends on the nature of the included changes:
  1. A patch release results in 0.0.2.
  2. Added functionality requires a minor version bump, so: 0.1.0.
  3. A breaking change bumps the major version number: 1.0.0. (Although versions pre 1.0.0 might still only bump the minor version and only go to 1.0.0 to convey a certain stability of the library.)
  4. Compatibility with a newer JanusGraph version bumps the equivalent version number: Supporting JanusGraph 0.4.0 would result in 0.1.0, whereas supporting JanusGraph 0.3.1 only results in 0.0.2.
The only downside I see with semantic versioning for the libraries is that they need to convey the supported JanusGraph version through another way, but that also seems to be necessary with your method as it's not clear just from a version number like 1.0.0 which JanusGraph version is supported. However, with pure semantic versioning we gain the increased flexibility we wanted to get with the independent versioning of those libraries.

What do you think?

Am Freitag, 28. September 2018 22:56:17 UTC+2 schrieb Debasish Kanhar:
Hi All,

A few days back, Florian had started a Discuss thread regarding how should we version the upcoming GLV libraries for Python and DotNet. After discussions and lazy consensus it felt like we should go forward with independent version numbers for the GLV libraries than the official JanusGraph.

Hence, coming back the main question then remains is even though independent how do we version the GLV libraries.

I've been following the following version semantics and would like to propose the same.

The GLV library will follow x.y.z version number where each are described as follows:
x: Corresponds to a particular JanusGraph major release version.
y: Corresponds to a particular JanusGraph minor release version
z: Corresponds to the path release for GLV library in itself.

For example, since we are starting to support begining JanusGraph 0.3.0, the following set of versions will be followed according to above proposed rule.

JanusGraph 0.3.0 : JanusGraph-Py 1.0.0
JanusGraph 0.3.0 : JanusGraph-Py 1.0.z [For all patches which are compatible with drivers for JanusGraph 0.3.0]

JanusGraph 0.3.1 : JanusGraph-Py 1.1.0 [Notice y change, because there was minor version change in JanusGraph]
JanusGraph 0.3.1 : JanusGraph-Py 1.1.z [For all patches for same JanusGraph version]

When JanusGraph bumps by Major version change like lets say 0.4.0,

JanusGraph 0.4.0 JanusGraph-Py 2.0.z
JanusGraph 0.4.1 JanusGraph-Py 2.1.z

And so on. The above rule helps in maintaining release plan for GLV libraries separately than JanusGraph in itself, and at the same time brings down a bit of commonality in bumps across major/minor version changes of JanusGraph and its Clients.

I'm still open to other ideas, so everyone, all suggestions are welcome.

Cheers
Debasish K


Re: [VOTE] JanusGraph 0.2.2 release

Debasish Kanhar <d.k...@...>
 

+1


On Wednesday, 3 October 2018 07:17:50 UTC+5:30, Jason Plurad wrote:
Hello,

We are happy to announce that JanusGraph 0.2.2 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.2

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.2/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad


Re: [VOTE] JanusGraph 0.3.1 release

Debasish Kanhar <d.k...@...>
 

+1


On Wednesday, 3 October 2018 07:18:31 UTC+5:30, Jason Plurad wrote:
Hello,

We are happy to announce that JanusGraph 0.3.1 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.3.1

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.3.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.3.1/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad


Re: [VOTE] JanusGraph 0.3.1 release

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

Reviewed the docs and all looks good.

+1


Re: [VOTE] JanusGraph 0.2.2 release

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

Reviewed the docs and all looks good.

+1


Re: Solr cloud with multiple ZK instances

Jerry He <jerr...@...>
 

Hi, Sarath and Madhan

Your analysis makes sense.

I did a quick test.
From gremlin shell: 
gremlin> graph.getConfiguration().getLocalConfiguration().getProperty('index.search.solr.zookeeper-url')
It only returns the first server out of the three servers in  'index.search.solr.zookeeper-url' from the property file.
On the other hand,
gremlin> graph.getConfiguration().getLocalConfiguration().getProperty('storage.hostname')
returns the list of three zookeeper servers for the hbase property.  storage.hostname is a String[] config option.  

We need to fix it, as you suggested.

Thanks for digging into it.

Jerry 


On Tue, Oct 2, 2018 at 2:34 PM, <madhan....@...> wrote:
The issue is trigged by CommonsConfigurations implementation, which calls getString(key) for String type values. When the value for the key is an array, getString(key) returns the first element - which causes JanusGraph to use only the first zookeeper host:port.

Changing SolrIndex.ZOOKEEPER_URL from "String" to "String[]" will end up calling getStringArray() , which will return all entries of the array.


On Tuesday, October 2, 2018 at 2:19:21 PM UTC-7, Sarath Subramanian wrote:
Jerry,


final String zookeeperUrl = config.get(SolrIndex.ZOOKEEPER_URL);

Always fetches single  string value, even if comma-separated zookeeper host values are specified. 

Maybe the fix is changing the data type from String to String array below?

public static final ConfigOption<String> ZOOKEEPER_URL = new ConfigOption<>(SOLR_NS,"zookeeper-url", "URL of the Zookeeper instance coordinating the SolrCloud cluster", ConfigOption.Type.MASKABLE, "localhost:2181");


Thanks,
Sarath 


On Friday, September 28, 2018 at 12:03:24 PM UTC-7, Jerry He wrote:
I think JanusGraph simply passes the  zookeeper-url string to the Solr cloud client without doing any parsing, and the string format is what Solr needs.
It is strange and puzzling that Solr's use of zookeeper client is not doing the re-connect.  Zookeeper client itself would do the fail-over reconnect (assume the correct servers and parameters are given to it).

Thanks,

Jerry

On Thu, Sep 27, 2018 at 10:03 PM, Apoorv Naik <na...@...> wrote:
Yes this is exactly what we're doing but if the first ZK server in the ensemble goes down the server runs into an endless retry loop, doesn't failover to other hosts at all.

Apoorv Naik


On Thu, Sep 27, 2018 at 9:58 PM Jerry He <je...@...> wrote:
Hi, Apoorv

Try:

index.search.solr.zookeeper-url=aid1:2181/solr,aid2:2181/solr,aid3:2181/solr

Replace hostnames and other info, with the members in you assemble.

Thanks,

Jerry 

On Thu, Sep 27, 2018 at 9:14 PM, Apoorv Naik <na...@...> wrote:
Hi Jerry,

I've a cluster where I've three Zookeepers deployed ( single ensemble) , the moment the first one goes down the Janusgraph instance becomes unusable and goes into an exception loop. So what I was trying to achieve was a failover to the other zookepeer server in the ensemble.

On Thursday, September 27, 2018 at 9:02:41 PM UTC-7, Jerry He wrote:
Hi, Apoorv

Can you explain what you want?  Do you mean multiple servers for a Zookeeper ensemble by 'multiple zookeeper instances'?  Or you mean multiple ensembles?

Thanks,

Jerry

On Thu, Sep 27, 2018 at 8:38 PM, Apoorv Naik <na...@...> wrote:
Looking at the documentation around using Solr in cloud mode, looks like there's only one zookeeper URL that's supported. How can I configure the JanusGraph instance to use multiple zookeeper instances instead of just one ?

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
To post to this group, send email to janu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/2c870817-b0f0-413e-955b-7739689eb0db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
To post to this group, send email to janu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/6b696132-af2a-436e-93c4-49e41a16289c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
To post to this group, send email to janu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/CAHkeaHVnHgzjTxsk7Y87GWFYRqCUh%3Dm_F7TOB4jvJQ79%2BHYKWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-use...@googlegroups.com.
To post to this group, send email to janu...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/CAOT1%3D38Sbe9q7x1jmMeV6kAGHH-9vHxFyZ8tp6Jg01ANCea3AA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-users+unsubscribe@googlegroups.com.
To post to this group, send email to janusgraph-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/125d6193-9e40-41bf-a569-085c7848f479%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


[VOTE] JanusGraph 0.3.1 release

Alexandr Porunov <alexand...@...>
 

+1


[VOTE] JanusGraph 0.2.2 release

Alexandr Porunov <alexand...@...>
 

+1


Re: [VOTE] JanusGraph 0.2.2 release

David Pitera <piter...@...>
 

+1

On Tue, Oct 2, 2018 at 9:47 PM Jason Plurad <plu...@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.2.2 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.2.2

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.2.2/janusgraph-0.2.2-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.2.2

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.2.2/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad


--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To post to this group, send email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/249e798a-db26-49cf-9328-405178d759ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [VOTE] JanusGraph 0.3.1 release

David Pitera <piter...@...>
 

+1

On Tue, Oct 2, 2018 at 9:48 PM Jason Plurad <plu...@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.3.1 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.3.1

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.3.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.3.1/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad

--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To post to this group, send email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/6c8d42ed-25e8-4e13-80fc-efea73f12353%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[VOTE] JanusGraph 0.3.1 release

Jason Plurad <plu...@...>
 

Hello,

We are happy to announce that JanusGraph 0.3.1 is ready for release.

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.3.1

A binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.3.1/janusgraph-0.3.1-hadoop2-doc.zip
        (See also documentation preview site)

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.3.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.3.1/docs/changelog.adoc

This [VOTE] will open for the next 3 days --- closing Friday, October 5, 2018 at 10:00 PM EDT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.


Thank you,
Jason Plurad

761 - 780 of 1596