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:
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:
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.
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?
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!
> 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?
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
On Sat, Nov 17, 2012 at 6:04 PM, Aseem Kishore <aseem.kish...@gmail.com>wrote:
> 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!
> On Sat, Nov 17, 2012 at 5:57 PM, Jim Webber <j...@neotechnology.com> wrote:
>> 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?
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
On Sun, Nov 18, 2012 at 8:13 AM, Wes Freeman <freeman....@gmail.com> wrote:
> 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
> On Sat, Nov 17, 2012 at 6:04 PM, Aseem Kishore <aseem.kish...@gmail.com>
> wrote:
>> 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!
>> On Sat, Nov 17, 2012 at 5:57 PM, Jim Webber <j...@neotechnology.com> wrote:
>>> 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?
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
On Mon, Nov 19, 2012 at 3:59 AM, Lasse Westh-Nielsen <
lasse.westh-niel...@neopersistence.com> wrote:
> 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
> Now, this has NOT been agreed, finalised or indeed implemented, so
> watch this space.
> - Lasse
> On Sun, Nov 18, 2012 at 8:13 AM, Wes Freeman <freeman....@gmail.com>
> wrote:
> > 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
> > On Sat, Nov 17, 2012 at 6:04 PM, Aseem Kishore <aseem.kish...@gmail.com>
> > wrote:
> >> 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!
> >> On Sat, Nov 17, 2012 at 5:57 PM, Jim Webber <j...@neotechnology.com>
> wrote:
> >>> 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?
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
On Mon, Nov 19, 2012 at 1:18 PM, Aseem Kishore <aseem.kish...@gmail.com>wrote:
> 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
> On Mon, Nov 19, 2012 at 3:59 AM, Lasse Westh-Nielsen <
> lasse.westh-niel...@neopersistence.com> wrote:
>> 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
>> Now, this has NOT been agreed, finalised or indeed implemented, so
>> watch this space.
>> - Lasse
>> On Sun, Nov 18, 2012 at 8:13 AM, Wes Freeman <freeman....@gmail.com>
>> wrote:
>> > 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
>> > On Sat, Nov 17, 2012 at 6:04 PM, Aseem Kishore <aseem.kish...@gmail.com
>> > wrote:
>> >> 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!
>> >> On Sat, Nov 17, 2012 at 5:57 PM, Jim Webber <j...@neotechnology.com>
>> wrote:
>> >>> 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?
On Mon, Nov 19, 2012 at 1:34 PM, Wes Freeman <freeman....@gmail.com> wrote:
> 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
> On Mon, Nov 19, 2012 at 1:18 PM, Aseem Kishore <aseem.kish...@gmail.com>wrote:
>> 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
>> On Mon, Nov 19, 2012 at 3:59 AM, Lasse Westh-Nielsen <
>> lasse.westh-niel...@neopersistence.com> wrote:
>>> 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
>>> Now, this has NOT been agreed, finalised or indeed implemented, so
>>> watch this space.
>>> - Lasse
>>> On Sun, Nov 18, 2012 at 8:13 AM, Wes Freeman <freeman....@gmail.com>
>>> wrote:
>>> > 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
>>> > On Sat, Nov 17, 2012 at 6:04 PM, Aseem Kishore <
>>> aseem.kish...@gmail.com>
>>> > wrote:
>>> >> 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!
>>> >> On Sat, Nov 17, 2012 at 5:57 PM, Jim Webber <j...@neotechnology.com>
>>> wrote:
>>> >>> 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?
> On Mon, Nov 19, 2012 at 1:34 PM, Wes Freeman <freeman....@gmail.com>wrote:
>> 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
>> On Mon, Nov 19, 2012 at 1:18 PM, Aseem Kishore <aseem.kish...@gmail.com>wrote:
>>> 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
>>> On Mon, Nov 19, 2012 at 3:59 AM, Lasse Westh-Nielsen <
>>> lasse.westh-niel...@neopersistence.com> wrote:
>>>> 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
>>>> Now, this has NOT been agreed, finalised or indeed implemented, so
>>>> watch this space.
>>>> - Lasse
>>>> On Sun, Nov 18, 2012 at 8:13 AM, Wes Freeman <freeman....@gmail.com>
>>>> wrote:
>>>> > 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
>>>> > On Sat, Nov 17, 2012 at 6:04 PM, Aseem Kishore <
>>>> aseem.kish...@gmail.com>
>>>> > wrote:
>>>> >> 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!
>>>> >> On Sat, Nov 17, 2012 at 5:57 PM, Jim Webber <j...@neotechnology.com>
>>>> wrote:
>>>> >>> 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?
