top | item 28155219

(no title)

arcatek | 4 years ago

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.

discuss

order

koheripbal|4 years ago

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|4 years ago

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

kbenson|4 years ago

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.

nwatson|4 years ago

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

tonyhb|4 years ago

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

orian|4 years ago

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|4 years ago

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|4 years ago

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

ThinkBeat|4 years ago

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|4 years ago

That's what Jetbrains does

_puk|4 years ago

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|4 years ago

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|4 years ago

Opposite(?) example is Windows NT 5.1 / 6.1

debarshri|4 years ago

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|4 years ago

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|4 years ago

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