semver specs changed?
Daniele Varrazzo
looking at semver.org, there is some crap going on.
the specs have been "updated" from 1.0.0 to 1.0.0-rc1. Note that the
latter was not a valid semver and that it sorts before the former
https://github.com/mojombo/semver.org/commit/9906c3febaef4a5e4053eeac6c51b82d29a48a06
Also note that the guy had formerly changed the spec by having the
pre-release separated by a point
https://github.com/mojombo/semver.org/commit/3561e20583ea220ae8364d5064f9d894b6088d61
So the specs previously accepted 1.0.0rc1 and rejected 1.0.0.rc1 or
1.0.0-rc1. Now it seems the latter is hip. 1.0.0.rc1 was a fad
instead...
Thus, we probably now have version numbers in pgxn that are no more
valid semver. Not only that, but the semver postgres implementation is
now less optimal, as the patchname field should be parsed in order to
sort. I don't know if it's worth optimize it as it would take some C
union juggling to maintain binary compatibility...
It sucks, isn't it? What should we do? Shall we update to the last
spec, hoping that he doesn't increase it from 1.0.0-rc1 to 0.1-beta4?
Shall we stop declaring we support semver and move to a versioning
scheme of our own, matching our current implementation?
By the way I actually prefer the - separator after the base version,
but I loathe the de-stabilization of the specs.
If we decide to move to the new specs, I can fix the postgres
extension as well as the python implementation. Don't know if you have
some perl code too in pgxn or if you only rely to postgres for
parsing/validation. The important thing is that the client and the
server match their implementation, or we'd end up with extensions that
can't be handled by the client.
Also, what about extensions already in pgxn whose version would change
(such as pgmp 1.0.0b3 - sorry, it's always my fault! we can purge it
from pgxn that's the only one): would re-index be enough to rewrite
the META (and any other file containing textual representation of the
version) and have the version as 1.0.0-b3?
-- Daniele
David E. Wheeler
> Hi David,
>
> looking at semver.org, there is some crap going on.
>
> the specs have been "updated" from 1.0.0 to 1.0.0-rc1. Note that the
> latter was not a valid semver and that it sorts before the former
>
> https://github.com/mojombo/semver.org/commit/9906c3febaef4a5e4053eeac6c51b82d29a48a06
>
> Also note that the guy had formerly changed the spec by having the
> pre-release separated by a point
>
> https://github.com/mojombo/semver.org/commit/3561e20583ea220ae8364d5064f9d894b6088d61
>
> So the specs previously accepted 1.0.0rc1 and rejected 1.0.0.rc1 or
> 1.0.0-rc1. Now it seems the latter is hip. 1.0.0.rc1 was a fad
> instead…
I’m not surprised. I talked to mojombo about it this summer at a GitHub-sponsored WWDC party. He told me he was thinking of adding a separator between the patch version and the optional string. I told him I thought it was a good idea, but strongly preferred the dash to the dot. He was also talking about allowing it to have up to four dot-separated parts, but I pushed back on that. His reasoning was because a lot of projects do that (Git and Rails, among them). I guess this change is a compromise on that
> Thus, we probably now have version numbers in pgxn that are no more
> valid semver. Not only that, but the semver postgres implementation is
> now less optimal, as the patchname field should be parsed in order to
> sort. I don't know if it's worth optimize it as it would take some C
> union juggling to maintain binary compatibility…
Yeah, looks like it will have to be split on the dots. What do you think, Sam? I need to read the spec changes in more detail to figure out what needs to change. Do you think it’s do-able?
Oh, there’s the new build version stuff. I think I would not support that on PGXN, which would leave packagers free to add it to PGXN releases that they package.
> It sucks, isn't it? What should we do? Shall we update to the last
> spec, hoping that he doesn't increase it from 1.0.0-rc1 to 0.1-beta4?
> Shall we stop declaring we support semver and move to a versioning
> scheme of our own, matching our current implementation?
The only part I think that breaks existing semvers is the new requirement of the dash, yes? I think I’ll file a bug report about that. I’d strongly prefer backward compatible changes to the spec, of course. And I’d probably keep the semver data type that way, anyway.
> By the way I actually prefer the - separator after the base version,
> but I loathe the de-stabilization of the specs.
Me too. Mojombo told me he hadn't released it as a final version, though, so he was still free to change that. The 1.0.0 seems to contradict that, but whatever, it’s his deal.
> If we decide to move to the new specs, I can fix the postgres
> extension as well as the python implementation. Don't know if you have
> some perl code too in pgxn or if you only rely to postgres for
> parsing/validation.
Yeah, I will have to update https://metacpan.org/module/SemVer.
> The important thing is that the client and the
> server match their implementation, or we'd end up with extensions that
> can't be handled by the client.
Agreed.
> Also, what about extensions already in pgxn whose version would change
> (such as pgmp 1.0.0b3 - sorry, it's always my fault! we can purge it
> from pgxn that's the only one): would re-index be enough to rewrite
> the META (and any other file containing textual representation of the
> version) and have the version as 1.0.0-b3?
I’ve [complained](https://github.com/mojombo/semver.org/issues/49). But even if Mojombo does not come around, we might be able to just say that the dash is optional in our implementations. Work for you?
Best,
David
Daniele Varrazzo
> I’ve [complained](https://github.com/mojombo/semver.org/issues/49). But even if Mojombo does not come around, we might be able to just say that the dash is optional in our implementations. Work for you?
I don't like "following specs - but...". I'd be happy to follow a
published spec with the assumption that it won't change. I see three
possibilities.
1. With the assumption that the guy won't change his mind in the
future, follow the new spec. The old spec maps unequivocally to a
subset of the new spec, because previously the dash was forbidden as
first char in the patchname and the plus was forbidden altogether. So
it is easy both to recognize an old-style ver by an alnum after the
third digit and to have to_semver() clean it up into a new-style one.
Ordering is respected by the transformation.
From the PG implementation PoV, it is easy to store the entire string
after the digits into the patchname member. When reading from the
heap, if the string doesn't start with + or -, a - is prepended. When
storing, the - can go in. Sorting would be fast when the structs have
different name or different +/- first char; if the versions only
differ by the pre/post release sequence, a slow comparison parsing the
string would be needed. I't stick to it instead of having an entirely
new on-disk representation of the datum, as I don't expect the semver
object to be stored in the millions in a db.
2. Ask the guy to leave the old spec as they were published as 1.0.0
and move to whatever they like but calling it 2.0.0 as backward
compatibility is broken. We would point to a webpage he should provide
with old versions of the spec. For this I would file a bug report more
specific than yours and ask both the publication of the old spec and
to move the new number out of 1.0.0.
3. We stop following and drop any reference to "semver" and make our
own versioning scheme, that would match the semver 1.0.0, to be
published on the pgxn website. No change to the code would be
required, only documentation.
Even if we don't care about the +, I think if we go for 1. we should
support it. As I said I don't like saying "we support semver except
point 11". Either we follow a standard... or we follow another one.
My order of precedence is 2, 1, 3 if Tom acknowledges he has broken
points 2 and 9 of his own spec and all the responsibility concepts he
brags about, and fixes the problem. If he is just pretending to be a
reliable person, I'd go for 3 without looking back.
-- Daniele