6 ms·

What's the "best" way to version your product?

6 points by sshadmand 10mo ago

There is the classic “Major.Minor.Patch”. Maybe git sha? I see this becoming popular this year: “year.version” from folks like Neo4J and Rivian.

mystifyingpoi 10mo ago
Define "best" and then define "your product". A library for a programming langugage will have very different idea about versioning than let's say, Microsoft Office.
raw_anon_1111 10mo ago
For public consumption - year.version. For libraries and even the internal version number of a public product like an OS release where developers still want to say. if os.version > x: standard semantic versioning.
eternityforest 10mo ago
I use semantic version for basically everything. Even for non-technical users, it's at least OK. Breaking changes are a pretty easy idea. Year.version might be better for marketing though.
sema4hacker 10mo ago
I developed and shipped one product with monthly releases for decades and always simply bumped the version by one: 1, 2, 3.. Anything fancier doesn't really tell you exactly what features changed when, so a table in the documentation spelled that out for each version.
- sshadmand 10mo ago
  Exactly! I mean, as long as the number moves forward and is unique it works. So, this idea that using year.number is the most human AND uid based version makes a lot of sense.
imperez 10mo ago
I have an iOS app and I stick with the usual semantic version scheme. It’s easy for me to use. If I jump to a new major version it’s easy to explain to users.
sloaken 10mo ago
I like the classic as it provides actionable information. Although knowing the date is nice, especially to indicate an application is dead end. But I rarely need that. When I first download it, and when I wonder ... hmm is this product ever going to be updated. I am not sure what the value of putting the year in the version. For my own home projects, and work pre-release, I always list the build date on the screen. Saved me more than a little frustration. You could combine them. Either Year.Major.Minor.Patch, or the other way around. But like I said before not sure of the value.
- sshadmand 10mo ago
  Agreed. It is funny that any idea can open a rabbit hole if you let it. e.g. why not do year.mo.day.min.second :-D I suppose it is finding the "perfect balance" for human reading and customer support.
toast0 10mo ago
It really depends on your release plans. If you are actually going to (attempt to) support multiple releases, semantic major.minor.patch is very useful. If you're really just going to support only the latest, semantic versioning is probably not so helpful, year.version is easy to figure out chronological differences with. githash as the only version identifier is a sign that you don't intend to help users track versions. This could be the right choice if you want to release something without expectations of use.
- sshadmand 10mo ago
  Yeah, that is a good way to look at it. Since this is for a website/web-app then we WILL "only support the latest". So will add that to the calculus. What I like about the trend toward "year" in the version is the instant ability to see the age of the version.
gardenhedge 10mo ago
Hasn't Ubuntu done year.version for a long time?
- sshadmand 10mo ago
  Yah - OSs have been doing it since window 95 at least, but seeing products "Switch" this year, that aren't OSs, was interesting.
gethly 10mo ago
I have very little experience this, despite having decades of programming under my belt. The +1 with each master branch merge proved to not be the best as we have seen many programs to switch to year and month type of versioning. Which makes sense as it clearly communicates WHEN the current version was the most up-to-date and it leaves no place for ambiguity. On the other hand, unlike products, libraries still make sense to version semantically as it is technical information for the users of those libraries that clearly communicates breaking changes.
luis_journey 10mo ago
Since my first app I use semantic versioning, because I think that it makes the most sense for the user.
apothegm 10mo ago
Depends. Who’s your user base?

6 points by sshadmand 10mo ago

There is the classic “Major.Minor.Patch”. Maybe git sha? I see this becoming popular this year: “year.version” from folks like Neo4J and Rivian.

mystifyingpoi 10mo ago

Define "best" and then define "your product". A library for a programming langugage will have very different idea about versioning than let's say, Microsoft Office.

raw_anon_1111 10mo ago

For public consumption - year.version. For libraries and even the internal version number of a public product like an OS release where developers still want to say. if os.version > x: standard semantic versioning.

eternityforest 10mo ago

I use semantic version for basically everything. Even for non-technical users, it's at least OK. Breaking changes are a pretty easy idea. Year.version might be better for marketing though.

sema4hacker 10mo ago

I developed and shipped one product with monthly releases for decades and always simply bumped the version by one: 1, 2, 3.. Anything fancier doesn't really tell you exactly what features changed when, so a table in the documentation spelled that out for each version.

sshadmand 10mo ago
Exactly! I mean, as long as the number moves forward and is unique it works. So, this idea that using year.number is the most human AND uid based version makes a lot of sense.

imperez 10mo ago

I have an iOS app and I stick with the usual semantic version scheme. It’s easy for me to use. If I jump to a new major version it’s easy to explain to users.

sloaken 10mo ago

I like the classic as it provides actionable information. Although knowing the date is nice, especially to indicate an application is dead end. But I rarely need that. When I first download it, and when I wonder ... hmm is this product ever going to be updated. I am not sure what the value of putting the year in the version. For my own home projects, and work pre-release, I always list the build date on the screen. Saved me more than a little frustration. You could combine them. Either Year.Major.Minor.Patch, or the other way around. But like I said before not sure of the value.

sshadmand 10mo ago
Agreed. It is funny that any idea can open a rabbit hole if you let it. e.g. why not do year.mo.day.min.second :-D I suppose it is finding the "perfect balance" for human reading and customer support.

toast0 10mo ago

It really depends on your release plans. If you are actually going to (attempt to) support multiple releases, semantic major.minor.patch is very useful. If you're really just going to support only the latest, semantic versioning is probably not so helpful, year.version is easy to figure out chronological differences with. githash as the only version identifier is a sign that you don't intend to help users track versions. This could be the right choice if you want to release something without expectations of use.

sshadmand 10mo ago
Yeah, that is a good way to look at it. Since this is for a website/web-app then we WILL "only support the latest". So will add that to the calculus. What I like about the trend toward "year" in the version is the instant ability to see the age of the version.

gardenhedge 10mo ago

Hasn't Ubuntu done year.version for a long time?

sshadmand 10mo ago
Yah - OSs have been doing it since window 95 at least, but seeing products "Switch" this year, that aren't OSs, was interesting.

gethly 10mo ago

I have very little experience this, despite having decades of programming under my belt. The +1 with each master branch merge proved to not be the best as we have seen many programs to switch to year and month type of versioning. Which makes sense as it clearly communicates WHEN the current version was the most up-to-date and it leaves no place for ambiguity. On the other hand, unlike products, libraries still make sense to version semantically as it is technical information for the users of those libraries that clearly communicates breaking changes.

luis_journey 10mo ago

Since my first app I use semantic versioning, because I think that it makes the most sense for the user.

apothegm 10mo ago

Depends. Who’s your user base?