Important: Neo4j version 1.10 may cause issues

[Aseem Kishore]

I've seen a couple of mentions of Neo4j's version number being bumped to 1.10 after 1.9.

I hate to be "that guy", but I wanted to chime in and say that might cause issues/bugs in code that was treating the version as a simple decimal number instead of as a string.

E.g. our own Node.js client library parses it to a float:

https://github.com/thingdom/node-neo4j/blob/develop/lib/GraphDatabase._coffee#L123

This means checks for which endpoint to use will fail in some cases, e.g.:

https://github.com/thingdom/node-neo4j/blob/develop/lib/Node._coffee#L134

Going forward, I can definitely fix node-neo4j's code to be more robust, and other client library authors should also, but the reality is that old(er) versions of client libraries will be out in the wild, even when people update to newer Neo4j versions.

So two questions:

1) For the immediate future, is it worth considering making the next version of Neo4j either 2.0 or 1.91 or 1.95 or something similar?

2) Long-term, perhaps the versioning scheme should be explicitly documented somewhere? And it should take into account the various snapshot and milestone releases. I would heartily recommend semantic versioning:

http://semver.org/

And ideally, sorting the snapshots and milestones could be simple lexographic sorting, not requiring knowledge of e.g. how "M" and "RC" and "S" and "GA" all fit together.

Thanks guys,

Aseem

[Jim Webber]

Hey Aseem,

> http://semver.org/

Allows for versions like 1.10.0 which, if we adopted this scheme, would be the number of the next Neo4j major GA release. Would that cause problems or is it the trimmed 0 (e.g. 1.10 only ) that causes grief?

Jim

[Aseem Kishore]

In the immediate future, the problem is just that at least node-neo4j was assuming version numbers were simple decimals. Adopting semver today doesn't fix that -- sorry if I inadvertently implied that. =)

So my short-term request (#1 above) was indeed asking if it's worth considering bumping to 1.91, 1.95, 2.0 or something else similar that will parse to a number > previous versions.

I was just suggesting semver as a scheme to adopt going forward, only because it seems like the current scheme is a bit custom, e.g. with GAs and RCs and milestones and snapshots.

Whatever scheme is chosen, I and other client library authors should update our code to parse versions precisely and robustly. My bad that at least I didn't from the start!

Jim

--

[Wes Freeman]

Not that my vote counts for much, but I vote for 1.10 or 1.10.0, because 1.9 -> 1.91 makes far less sense to me, regardless of how it would be easier to treat the version numbers as strings or floats. Sorry Aseem. :P

I like the Neo release system and the way milestones are released--unfortunately it does mean a bit more work if you want to parse the version, but usually it's good enough to just get the major and minor.

It might be slightly easier to parse if there were always 3 numbers like 1.9.0-M01, but at this point I'm all for consistency and continuing the way it has been, to avoid having special cases for when the actual version numbers starting changing.

Wes

--
 
 

[Lasse Westh-Nielsen]

Current thinking on versioning takes into account three things:

- we want to be able to trace artefacts (so no more anonymous snapshots)
- we still want the effect of a snapshot, i.e. you can depend on 1.9
milestone 2 and get the latest published build of that on a regular
basis without having to manually update version numbers
- whatever we do needs to work primarily with Maven

That leads to a scheme like this: <major>.<minor>.<patch>-<milestone/
release candidate token>_<build number>

Major, minor and patch are potentially multi-digit integers, so yes
Aseem, robustness is needed ;) The last bit,
"<milestone>_<build_number>" is sorted alphabetically, so we need to
pad numbers:

- M01_0099 < M01_0117 => 4 digits for build number gives up to 9999 builds
- M09_42 < M10_87 => 2 digits for milestone version or RC version
gives up to 99 of those

Examples in ascending order:

1.2.3-M01_42
1.2.3-M01_43
1.2.3-M01_44
1.2.3-M01
1.2.3-M02_48
1.2.3-M02_49
1.2.3-M02
1.2.3-RC01_51
1.2.3-RC01_52
1.2.3-RC01
1.2.3-RC02_54
1.2.3-RC02
1.2.3
1.2.4-M01_65

This supports Maven version ranges, for the effect of a snapshot:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges

Now, this has NOT been agreed, finalised or indeed implemented, so
watch this space.

- Lasse

> --
>
>

[Aseem Kishore]

Cool, that scheme sounds good to me. It'd be great to know if/when this is formalized and documented somewhere.

I can understand if you guys stick with 1.10 for the next version, but it'd be good to ask other client library authors to check their code -- will that cause issues/bugs in any other libraries?

Aseem

--

[Wes Freeman]

I don't have any conditions to check versions in code (in AnormCypher). My plan is to just not support old Neo4j versions that don't have a /cypher REST endpoint. I should probably document that--thanks for reminding me.

I am curious what you're checking for...

Wes

--
 
 

[Aseem Kishore]

Currently just one case within the library, for the old vs. new indexing API:

https://github.com/thingdom/node-neo4j/blob/develop/lib/Node._coffee#L134

Aseem

--
 
 

[Wes Freeman]

Cool. Good to know about that.

Wes

--