fsaintjacques / semver-tool

semver bash implementation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

prerel compare issue

deschrevel14 opened this issue · comments

Hello,

Following is correct :

$ ./semver.sh compare 0.2.0-rc3 0.2.0-rc2
1

But the following compare should return -1:

$ ./semver.sh compare 0.2.0-rc3 0.2.0-rc21
1

Maybe with 2 digits prerel :

$ ./semver.sh compare 0.2.0-rc03 0.2.0-rc21
-1

But the recent bump prerel is moving from 2 digits to 1 :

$ ./semver.sh bump prerel 0.2.0-rc01+1.2.8
0.2.0-rc2

Thanks for the code

First off, I do not believe that compare is broken.

$ ./semver.sh compare 0.2.0-rc3 0.2.0-rc21
1

is correct. "rc3" has higher precedence than "rc21" according to the semver standard.

My understanding of your issue is that you are requesting that bump prerel should preserve leading zeros in trailing numeric portions of alphanumeric identifiers when bumping the pre-release. The motivation is to avoid (up to a point) the problem of lexicographic vs. numeric comparisons.

I can sympathise with this as this is a work-around from almost before time. Reminds me vaguely of Y2K. But it is a work-around.

The semver folks attacked this problem head-on in the spec: numeric id's are not allowed to have leading zeros (unless the id is a single zero). And they specified that these numeric id's be compared numerically: which is why you can't use simple string comparison tools on semantic versions.

Note that the best (non-work-around) way to handle this is just to use numeric id's like:

$ ./semver.sh compare 0.2.0-rc.3 0.2.0-rc.21
-1

Now, the recent bump prerel functionality adds a bit of help in that it will append or increment a trailing numeric portion of an alphanumeric id. When I started this code, I considered that the pre-release bump should only append or increment numeric ids. If people were not going to use well supported numeric ids to solve this comparison problem, then that was their problem! Best practice pre-release versions would be things like "1.2.2-beta.1", "1.0.1-rc.2", etc. When you read the spec., there is not even an example showing "rc1"'s or "beta02"'s. The sense of the spec is 1) don't use leading zero's; 2) use numeric ids if you want sequential ordering.

But, (perhaps unfortunately), I relented. Out in nature one does find "rc2". Maybe some conventions or scripts depend on this format? So, maybe being a bit forgiving was in order. Sort of like accepting a leading "v".

Ok, the code could be added. However:

  1. It adds a bit more (tricky) logic to the code.
  2. It requires a major version release of semver-tool.
  3. It pushes the problem out, but does not completely solve it.
  4. Using numeric id's do solve it.
  5. Does this change address a real need and use case?

So, I'll wait for feedback. Especially on point 5.

Hello Ranger6,
Thanks for this clear explanation.
Yes, the dot to identify numeric id is the best solution for our case. We can change from -rc2 to -rc.2.
About your point 5 : We do not have a strong use case that cannot be covered by numeric id. Rc is for release candidates that are produced only for tests. They are not communicated widly, not referenced very much.

I think we all agree that this issue is resolved: won't fix (see discussion above).