Hacker News Reader

Comment by koheripbal | Hacker News Reader

Maybe I'm aged, but I always just use the date. If I build today, the version will just be 210811.1 and it updates automatically in each build.

I'm a one man shop though so I never branch for major/minor releases.

View on HN

> I'm a one man shop though so I never branch for major/minor releases.

Honestly, for my one-man projects I use 0. to indicate "there is absolutely no backwards compatibility guarantees because I'm still fucking around" and 1. to indicate "this is in prod and I'm confident about it" (with attendant discipline on how semver major/minors are supposed to be used).

Yes, and 2 is "I probably broke your favorite API."

Probably?

That's regular Semantic Versioning

https://semver.org/

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

> Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.

> If your software is being used in production, it should probably already be 1.0.0.

Basically, nobody wants to deal with backcompat. Having worked somewhere where we supported stuff more than a decade old, it's not entirely surprising. It's really hard to know what crazy stuff customers are doing with your stuff, and fun new things often die off during the pitch.

think of react-native being used in production for years while it's in 0.x.x

Ask me how I can tell you haven't been using this strategy for more than a decade or two. ;)

I say that mostly jokingly, but stuff like this was really annoying around the turn of the century, in a death by a thousand cuts kind of way.

Please, just put the full year in. It's only two more digits, and will prevent the older people that see it from building a little bit of rage up every time they see it.

Y2K100, aye!

Or even trying to determine which value represents year, month, or day. Internet date format is the only way to go, IMO.

I've been using it for over 20 years...

This works well only if you're supporting a linear evolution of releases, no branching or LTS or back-porting.

There’s nothing that says you can’t have patches in calver, as e.g. `YY.MM.patch`. So you can definitely have an LTS calver release, or even back port new features. You just have to do it in the patch version, or adopt some other variation of the scheme, e.g.`YYYY.minor.patch` or `YY.MM.minor.patch`

Yep. This is what Ubuntu does, roughly. Version 2020.04 is LTS and will get security updates until 2030 April (04)

This is the exact strategy we use for our rollouts too. 2021-08-12.01 was just released.

minor/major makes sense for, when a company plans to support a major for longer period of time, if the development is continuous, the date sounds good

I've come to the same conclusion for the main product which always moves forward and currently has limited and tightly coupled relations. If the product gets lots of external consumers, then making it more versioned might make sense.

But for common libraries SemVer feels good solution for not breaking the main products and helps making developers to think about breaking changes etc.

What are you going to do when it is August 11th 2121? Reuse the build number?

Add a 1. in front. It earned it.

If the project actually does last that long, I'm sure it wouldn't be hard to just extended the version by 2 digits to include the full year.

Is it a Mozilla project because that is some Mozilla type version inflation?

You mean that you're _sure_ that nothing will be dependent on the format of the version string of a >100yo project?

I'd bet everything I own against that

not a problem. it's physically impossible for any software to be maintained that long.

you can't prove me wrong

Sure I can. It will just take some time to do so.

Instruct the AI to move the project to a versioning system that supports full calendar year.

This is a solved problem.

[Y2K Programming solutions]: https://en.wikipedia.org/wiki/Year_2000_problem#Programming_...

This is what makes sense to me as well.

It is also much easier to reference when talking with other devs, users, etc.

We all know the calendar and a date is much easier to remember.

Straight increases 5, 6, 7 ar also easier for user to reference.

That's what Jetbrains does

Reply on news.ycombinator.com