[arcatek]

I know you're joking, but I worked in a startup where a massive effort was made to completely rebuild the 1.x website - both backend and frontend. It required a lot of work from everyone, and I remember we even stayed late more than a few times to bring it to finish line.

So it was a bit disheartening that the founders never bumped the version to 2.x once the rollout was achieved. It's perhaps a bit nitpicky, but it felt like the work wasn't properly appreciated.

[koheripbal]

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.

[dnautics]

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

[failrate]

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

[still_grokking]

Probably?

[gowld]

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.

[zamalek]

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.

[aabbcc1241]

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

[kbenson]

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.

[gowld]

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

[codetrotter]

Y2K100, aye!

[JoBrad]

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

[nwatson]

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

[goerz]

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`

[MiddleEndian]

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

[tonyhb]

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

[orian]

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

[trm42]

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.

[tssva]

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

[dmos62]

Add a 1. in front. It earned it.

[ruined]

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

you can't prove me wrong

[tssva]

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

[ziml77]

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.

[williamdclt]

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

[tssva]

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

[thih9]

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

[Jiocus]

This is a solved problem.

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

[ThinkBeat]

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.

[PikachuEXE]

That's what Jetbrains does

[_puk]

Unfortunately I've found there often needs to be separate internal and external version numbers.

An internal rewrite where all the "old bugs" are fixed, but minimal new features are added may feel like a 2.0 for those who worked on it, but for external customers it's the same tool, with the same functionality, just maybe looks a little different.

A 2.0 is often heralded with marketing fanfare, so it needs justification.

I'm not saying it's right, or that one rule fits all; I've seen it first hand and feel your pain.

[yjftsjthsd-h]

And on the flip side, sometimes internal version 11.3 is a boring release with only small changes since 11.2, but if one of those changes was a feature that marketing cares about then bumping to The New Exciting 12 may be in order.

[fomine3]

Opposite(?) example is Windows NT 5.1 / 6.1

[debarshri]

I have seen completely opposite things in my previous startup I worked for. The product wasn't event production ready, they would call it version 1.0, version 2.0 and now version 3.0

Versions were bumped now and then, without real major changes.

They use this as marketing gimmick to create buzz that something major is being released but actually it was same old stuff just not ready for primetime.

[tomc1985]

It is so weird how many people seem to have a stake in the version number. Personally I'm all for date or build numbers, and removing version numbers entirely

[hzhou321]

Yeah, after 1.x, the 2.0 is one last savior. Beyond that, there is no hope.