3 ms·

World never asked for this. ;) Seriously though - any versioning scheme, as long as it's consistent, is fine. Like everything in the world, this has some pros a

World never asked for this. ;) Seriously though - any versioning scheme, as long as it's consistent, is fine. Like everything in the world, this has some pros and cons compared to typical semantic versioning: it does remove some of the noise/confusion in exchange for potentially exploding release number. If you're releasing often, semver probably makes more sense. If you're releasing at a glacier pace but break BC from time to time, this looks like a good match.

curryhoward 10y ago
Genuinely curious, what is the problem with "exploding release number"s?
- DominikD 10y ago
  We've had this problem in one of the internal projects in the past where version would change so rapidly we basically didn't care about some of them. By the time team A did something to .70 there was already .75 released by team B. What do you do to, say, .72 - port changes? Ignore it? Does anyone actually care about in-betweens? This also increased cognitive load: if I have 5 versions to care about I actually have better understanding of what went where, why, etc. With hundreds of versions institutional memory wasn't as strong. I feel that if we were to push minor updates (ones only team B cared about) to a separate portion, everyone would be better off. This changed for later projects and simplified workflow (you could actually remember things).
  - Nokinside 10y ago
    >What do you do to, say, .72 - port changes? Ignore it? Does anyone actually care about in-betweens? It seems that your project was misusing version management. Despite the name, version management is not actually taking care of managing your software versions for your project. It takes care of the bit level versions, you still need people to manage the semantics and human side of it. If different groups can push an pull things without anyone accepting, rejecting and deciding what is release branch and development branch, you are doing it wrong.
- deleted 10y ago
  [deleted]
vinceguidry 10y ago
> World never asked for this. He did call it a manifesto. That's the whole point.

curryhoward 10y ago

Genuinely curious, what is the problem with "exploding release number"s?

DominikD 10y ago
We've had this problem in one of the internal projects in the past where version would change so rapidly we basically didn't care about some of them. By the time team A did something to .70 there was already .75 released by team B. What do you do to, say, .72 - port changes? Ignore it? Does anyone actually care about in-betweens? This also increased cognitive load: if I have 5 versions to care about I actually have better understanding of what went where, why, etc. With hundreds of versions institutional memory wasn't as strong. I feel that if we were to push minor updates (ones only team B cared about) to a separate portion, everyone would be better off. This changed for later projects and simplified workflow (you could actually remember things).
- Nokinside 10y ago
  >What do you do to, say, .72 - port changes? Ignore it? Does anyone actually care about in-betweens? It seems that your project was misusing version management. Despite the name, version management is not actually taking care of managing your software versions for your project. It takes care of the bit level versions, you still need people to manage the semantics and human side of it. If different groups can push an pull things without anyone accepting, rejecting and deciding what is release branch and development branch, you are doing it wrong.
deleted 10y ago
[deleted]

vinceguidry 10y ago

> World never asked for this. He did call it a manifesto. That's the whole point.