4 ms·

“There’s no way to…” is maybe imprecise phrasing but this is a real problem. Marketing departments really want to use that first number for Big Important Relea

“There’s no way to…” is maybe imprecise phrasing but this is a real problem. Marketing departments really want to use that first number for Big Important Releases and only Big Important Releases. I have seen products get their version incremented from 2.x.x 3.0.0 to indicate that an entirely different product (that could be deployed alongside the first but was otherwise unrelated) was being launched.

mlhpdx 3y ago
That doesn't sound like an issue with semver (or pragmatic). There is no versioning convention that will prevent people from being people. A rigid, automated (magical) versioning _system_ might do that, but not a convention/standard. I find semver extremely helpful, both as an author and consumer. It may make me think a little for some packages about where I want to pin things, but at least it makes the mechanics of pinning them sensible. Edit: packets -> packages
- natbennett 3y ago
  Server is very helpful in many contexts, especially libraries and packages, and that don’t have associated commercial support obligation. It has real drawbacks for on-premise software with commercial support obligations, and shouldn’t be used automatically just because it works well for libraries.
ajmurmann 3y ago
I've also seen the opposite where an organization night be hesitant to release a new major because it comes with long contractual support obligations.
- natbennett 3y ago
  Yep. Same project regularly shipped breaking changes in “feature” updates.
  - ajmurmann 3y ago
    I am not sure we are talking about the same project. However, the one I am thinking of had a interesting challenge where a security issue required making the default configuration requiring a allow-list for a certain long-existing feature. This ended up going out in a patch, even though it's a breaking change. I am still uncertain what the ideal solution would have been. Following SemVer 100% would required this to be a major. However, all supported versions needed this change. Forcing users from really old majors and minors to jump to a new major with all kinds of new stuff is less than ideal. The alternative would have been to ship multiple new majors that are really just upgrades to the old minor that they are patching. WHile technically correct, also crazy.
- WorldMaker 3y ago
  I've also seen too much of marketing is watching the project iterate too closely, it's a Ship of Theseus, and they never know when to declare a "Big Release" anyway. In six months all of the planks are different, but it happened so slowly for marketing they still think it is the same ship. Projects just get stuck in 1.x marketing version because marketing has no idea where major releases should go. They want always up to date SaaS but then are confused they can't market it like the big Waterfall adventures of yesterday. At least with semver they might be forced to say something. I've done that a few times where the marketing version number displayed in the app is effectively just 1.{semver major}.{semver minor} and "just tell us when you want to bump that 1 to a 2 or something" getting the response "well, it hasn't really changed all that much from 1.0, has it?" and then pulling out the receipts of something like 30+ semver breaking differences in X months.
yjftsjthsd-h 3y ago
So just tack on a number - marketing.breaking.feature.patch - or market on the feature number (Solaris 11 uname will happily tell you its real version is 5.11)
- natbennett 3y ago
  Yes, “just stop using semver” is basically the solution to enterprise versioning
- CSMastermind 3y ago
  Okay I now very strongly support renaming the numbers to be more explicit whether we add more of them or not. Literally calling the numbers 'breaking' and 'feature' would have made things more clear.
clausecker 3y ago
You could also have separate marketing and compatibility release numbers.

mlhpdx 3y ago

That doesn't sound like an issue with semver (or pragmatic). There is no versioning convention that will prevent people from being people. A rigid, automated (magical) versioning _system_ might do that, but not a convention/standard. I find semver extremely helpful, both as an author and consumer. It may make me think a little for some packages about where I want to pin things, but at least it makes the mechanics of pinning them sensible. Edit: packets -> packages

natbennett 3y ago
Server is very helpful in many contexts, especially libraries and packages, and that don’t have associated commercial support obligation. It has real drawbacks for on-premise software with commercial support obligations, and shouldn’t be used automatically just because it works well for libraries.

ajmurmann 3y ago

I've also seen the opposite where an organization night be hesitant to release a new major because it comes with long contractual support obligations.

natbennett 3y ago
Yep. Same project regularly shipped breaking changes in “feature” updates.
- ajmurmann 3y ago
  I am not sure we are talking about the same project. However, the one I am thinking of had a interesting challenge where a security issue required making the default configuration requiring a allow-list for a certain long-existing feature. This ended up going out in a patch, even though it's a breaking change. I am still uncertain what the ideal solution would have been. Following SemVer 100% would required this to be a major. However, all supported versions needed this change. Forcing users from really old majors and minors to jump to a new major with all kinds of new stuff is less than ideal. The alternative would have been to ship multiple new majors that are really just upgrades to the old minor that they are patching. WHile technically correct, also crazy.
WorldMaker 3y ago
I've also seen too much of marketing is watching the project iterate too closely, it's a Ship of Theseus, and they never know when to declare a "Big Release" anyway. In six months all of the planks are different, but it happened so slowly for marketing they still think it is the same ship. Projects just get stuck in 1.x marketing version because marketing has no idea where major releases should go. They want always up to date SaaS but then are confused they can't market it like the big Waterfall adventures of yesterday. At least with semver they might be forced to say something. I've done that a few times where the marketing version number displayed in the app is effectively just 1.{semver major}.{semver minor} and "just tell us when you want to bump that 1 to a 2 or something" getting the response "well, it hasn't really changed all that much from 1.0, has it?" and then pulling out the receipts of something like 30+ semver breaking differences in X months.

yjftsjthsd-h 3y ago

So just tack on a number - marketing.breaking.feature.patch - or market on the feature number (Solaris 11 uname will happily tell you its real version is 5.11)

natbennett 3y ago
Yes, “just stop using semver” is basically the solution to enterprise versioning
CSMastermind 3y ago
Okay I now very strongly support renaming the numbers to be more explicit whether we add more of them or not. Literally calling the numbers 'breaking' and 'feature' would have made things more clear.

clausecker 3y ago

You could also have separate marketing and compatibility release numbers.