Debasish Kanhar <d.k...@...>
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.