+1

Thanks for trying this out with PyPi and yes, you got my suggestion exactly right. Unfortunately, I think that my suggestion wouldn't even completely work for NuGet like I proposed it earlier, exactly

Everyone, I think Florian's idea can be modified a bit to support Python's PyPi versioning. If I'm correct, Florian suggested following structure: X.Y.ZZAA Where X: JanusGraph majov version number:

+1 Am Dienstag, 9. Oktober 2018 23:09:57 UTC+2 schrieb Alexandr Porunov:

+1

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

Hi all, During my work on Testcontainers (https://github.com/GDATASoftwareAG/janusgraph/tree/testcontainers), I needed to modified all tests files multiple times. These multiple changes can follows

Florian, Stephen. Thanks guys for your input. That was really a helpful comment but I was doing quick testing on what Version numbers are supported on PyPi (Where Python libs are hosted). 1. So, It

This vote is now closed with a total of 8 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (3 -- Jason Plurad, Misha Brukman, Jerry He) 0 (0) -1 (0) NON-BINDING VOTES: +1 (5 -- David

Thanks for yourinput on this, Stephen! This really got me thinking. I think in the endit comes down to the question of what is more important for us tocommunicate to users with the version: Which

+1 Downloaded the binary zip. Checked the signature. Good. Unzip it. Looked at the directories and files. Good. Ran simple transactions and queries against HBase 1.2.6 and Solr 6.3.0.

I haven't been really following the discussion, so apologies if this has already been mentioned, but I've liked the approach that Ogre and gremlin-scala have taken with respect to TinkerPop - they

I opened up Issue 1285 for the storage incompatibility of upgrade from 0.2.1 to 0.2.2. I will start a new voting thread for 0.2.2 when the release with a fix is ready.

If we agree on using SemVer, then that already tells us how to handle minor and major version. Taken from its summary: The only special case is that we can include breaking changes without having to

and users expect exactly that of a library that has a 0.y.z version. I think that makes sense for us. : I agree with you, after going through your points, it seems that going forward with 0.y.z as

Also, nice catch :)

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

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:

+1

+1