Support version numbers from the wild #5
Replies: 3 comments
|
I put a lot of thought into this question in a post last year. I got very little pushback, in part because pretty much any version can be converted to a SemVer. Furthermore, it doesn't prevent extension authors from continuing to use their own version formats in the control file and therefore the database. One need only convert it to SemVer for the PGXN I'm not opposed to changing how versions work in PGXN v2 (if I get the opportunity to continue working on it), but so far I also don't see a compelling reason to do so. Still, I should probably draft an RFC for versioning and solicit feedback there. In any event, PGXN v1 won't be changing version semantics; it's pretty deeply ingrained in its operation. |
|
It might seem silly, but I am not going to lie about the project version number. |
|
In my mind it's not a lie when there's a direct translation and no deception. But I agree that it could be confusing for someone who needs to install foobar 1.2 and can only find foobar 1.2.0. |
Uh oh!
There was an error while loading. Please reload this page.
Currently, PGXN insists on semver for version numbers. But projects out there use all kinds of versioning schemes. Insisting on semver is driving extension authors away (it is at least me).
Debian has a formal specification for version numbers that is much more flexible:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version
RPM has similar semantics.
All reactions