You're not mature enough to release your first version as v1

https://www.jvt.me/posts/2024/08/26/v0/

by ingve • 2 years ago

18 15 2 years ago

Woshiwuja4• 2 years ago

Version numbers dont mean anything unless you make clear you are using semver. does starting from 0.0.1 or 1.0.0 change anything? not really

meiraleal• 2 years ago

1.0 being the first stable release of a project is an obvious convention older than semver

Woshiwuja4• 2 years ago

Was it ever a standard? not so obvious

jamietanna• 2 years ago

True! But there are a number of ecosystems where it's implied that you use SemVer i.e. Go in https://go.dev/doc/modules/version-numbers

Woshiwuja4• 2 years ago

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

winternewt• 2 years ago

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.

cmeacham98• 2 years ago

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".

ziml77• 2 years ago

But don't keep your project on v0 forever. If it is production-ready, then it should be v1 to signal that.

Woshiwuja4• 2 years ago

what if you didnt break any apis? it will stay at 0. Seeing 0.x doesnt mean its not production ready

snakeyjake2• 2 years ago

No human being, for the entirety of human history, has ever looked at v1 and thought "hmmm version one, that must mean it's a stable release!"

Normal human beings look at v1 and go "yeeeeesh here we go!"

All software everywhere should be versioned YYYY.MM.DD.

That 0.62.3.1b-45x-fart nonsense has to go.

YYYY.MM.DD

If compatibility is broken VERSION THE NAME.

01HNNWZ0MV43FF• 2 years ago

That's SemVer except integrating the major version into the name and the patch version and minor version into the date

SahAssar2• 2 years ago

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).

snakeyjake2• 2 years ago

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.

You're not mature enough to release your first version as v1

Related Stories