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)
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 didn't know that having major version 0 implies that API may change
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
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?
How do we bump minor and major versions?
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
--
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-de...@googlegroups.com.
To post to this group, send email to janusgr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/e8e0daa5-e0d0-48b1-9219-809c47fe5e33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Thanks for your input on this, Stephen! This really got me thinking.
I think in the end it comes down to the question of what is more important for us to communicate to users with the version: Which version of JanusGraph (and therefore implicitly TinkerPop) is supported or whether new features or breaking changes are included in the library itself that are not related to an updated JanusGraph version?
The more I think about this, the more I tend towards primarily communicating the supported JanusGraph version. Once the libraries support all JanusGraph specific predicates and data types, there won’t be many changes to them. The only changes will probably be updated dependencies which is mostly the TinkerPop GLV and those versions will be in line with the TinkerPop version supported by JanusGraph. So, I guess the optimal solution for the library versions would include the supported JanusGraph version. That would also have the advantage that users won’t have to keep track of yet another version and ensure that everything is compatible (the compatibility matrix of JanusGraph is already complicated enough).
Unfortunately, we can’t completely copy the versioning strategy from Ogre as it uses 4 version elements and some package managers (like NuGet) expect SemVer style versions with only 3 elements. We could solve this by taking the JanusGraph version and then extending the third element with a version number for the library itself. So, something like this:
How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.
So, my suggestion is that we use semantic versioning for the libraries and start with 0.1.0.
How do we support both clients at same time? We are at, let us say version 0.1.7 for client, then what would be the version with TP 3.3 (Corresponding to JG 0.3.5) and the one corresponding to TP 3.4 (JG 0.4) be named? Both the clients are going to have essentielly same features, but vary in just the TinkerPop versions.
...