Live data from Hacker News

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

news.ycombinator.com

11–16 of 16 posts

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

#12

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.

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.

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

#13
post #7

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. S…

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.

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

#14
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.

Post reply on HN