Of course tooling should permit 0.x.y releases but I think the author vastly overestimate their value. The point of semver is to know what has changed between releases. If your 1.0.0 API was not good, just release 2.0.0. It's not under obligation to have any compatibility whatsoever with v1.
If you're using semver, it has a special allowance for 0.X.Y releases that says they can break at any time.
Thus, 1.0.0 is not equivalent here if you want to signal to your users "we're doing rapid iteration and the API might change at any time before our first stable release".
I'm a living disproof of your comment regarding v1. Besides that time-based versioning communicates nothing besides the release time, which is basically useless for anything except perhaps a root trust store or the tzdb.
1.3.2-alpha3 gives me so much more info than 2024.08.27, even besides that fact that YYYY.MM.DD disregards that you sometimes release the same software multiple times a day.
Why would you even care when the version is released? You care about compatibility and if it is secure (which needs to be tracked out of band anyway).
>Why would you even care when the version is released?
I don't. The actual numbers, both in my example and yours, are almost irrelevant.
Your example only communicates more info if you know what constitutes a major and minor release for that specific project, which (let's be real here) you don't-- hell nine times out of ten the project itself doesn't know that. And if you do, then you also know which milestones were reached or are planned for specific dates.
My example sorts nicely. Looks pretty. Gives you an idea at a glance how old and busted your stuff is.
> I don't. The actual numbers, both in my example and yours, are almost irrelevant.
So why would you make them less relevant? With semver packages that do proper versioning actually communicate something meaningful and for packages that don't do proper versioning it's just a number like in your proposal.
> Your example only communicates more info if you know what constitutes a major and minor release for that specific project
For semver that is defined and even if only loosely followed still gives an indication of the intention.
> My example sorts nicely.
Use sorting that understands the context. `sort -h` works for bash. For v0.0.0-alpha1 and similar stuff date-versioning does not help either.
> Looks pretty.
Subjective and not useful.
> Gives you an idea at a glance how old and busted your stuff is
That assumes that every library/package needs constant updates. Many packages only needs updates every couple of years. Nothing about how "busted" your stuff is is communicated.
---
I still don't understand why you consider release date something that is meaningful to communicate in the version? Even if the author is wrong about compatibility 99% of the time it would still be better to use semver than date-versioning since it would still give you an indication of if the author feels the compatibility is broken. Date just says the date, which is meaningless for compatibility or features.
you are right, i was talking about the times it isnt implied or forced onto you. Notably also Go does that if you dont specify the version, in the Pseudo Version Number section, which is a more sane way to version stuff in my opinion
Individual projects and companies often had standards that they communicated to their users. Some treated it as a progress indicator where 1.0 was considered "done" according to the planned features, but each 0.X release was ready for production. Others would not recommend production use until 1.0.
In any case, most users expected 1.0 to be ready for production and stable.
As a work-around for tools that don't support 0.x releases, I guess they could mark it as 1.0-UNSTABLE or something, but I think most would assume that a 1.0 release implies a more stable API than a 0.1. This can lead to misunderstandings and unnecessary friction.
The tool mentioned in the article seems to enforce an opinionated view of development that results in partial support for semantic versioning. The developers of this library has a certain view of how semantic versioning should work, which they are free to have of course. We can't force them to implement the full standard, but it is still valid to ask questions.
The semantic-release README claims "strictly following the Semantic Versioning specification and communicating the impact of changes to consumers.". I guess it is technically correct as they support a partial implementation, but it is not what I expect when reading this statement. While the features they support are implemented according to the standard, it's not complete. I also think that the "communicating the impact of changes" part can be confusing when an upgrade from 1.0.0-alpha to 1.1.0-alpha allows major API breakage just because it uses a pre-release naming syntax.
