9 ms·

I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping t

I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number, but I don't like that either. Thinking on it now, I wish instead of major.minor.patch the format was major.breaking.minor.patch, where the first component is for "significant" releases, and the second component is what you use when you're simply introducing breaking changes (but doesn't qualify as a "significant" release).

humanrebar 10y ago
> major.breaking.minor.patch That's the same thing as projectName.major.minor.patch in some respects. You could just rebrand the project if it's a completely different direction. There's not a technical reason to keep the name, just a marketing/political/organizational reason.
- thomaslee 10y ago
  Exactly. You can keep the brand while still communicating the fact it's an overhaul.
- eridius 10y ago
  A significant release does not mean it's a completely different direction. It just means that it's significant in some sense.
cbdfghh 10y ago
> I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number, but I don't like that either. When you're doing backend/API things (where breaking changes matter), I sure hope you think a million times before making breaking changes. Can you imagine if someone had to go through millions of lines of his code to make sure nothing broke, then, a week later, you broke his code again?
- thomaslee 10y ago
  I'm not the parent, but I sort of like the idea at first glance. I mean, it's a fine line: if I have "v1.0.0" and I break one API in one module, I'm compelled to release "v2.0.0" even though v2.0.0 is otherwise entirely compatible with v1 -- it's not as big of an upgrade as the version numbering system would imply. But if I go and drastically change things in a way likely to impact many users, that gets a brand new version number too. So v1.0.0 -> v2.0.0 only really communicates "something might break". The scheme proposed by the parent would be able to communicate "expect many things to break because I refactored the heck out of stuff to fix some long-standing design deficiencies" -- though admittedly when to bump that first version number is likely to be a subjective topic. :) Perhaps this isn't as valuable as it seems at a first glance, but if anybody's tried something like this I for one would be interested to hear about it.
  - humanrebar 10y ago
    The point of making backwards compatibility the first number is because the subtle changes need attention drawn to them. There's little risk of people accidentally using things in a broken way when projects are renamed. It's about clarity of technical communication. There are lots of ways to communicate big direction changes, including changing the look and feel of something, adding code words (WD Caviar Green), putting out a big publicity push (v32 is a whole new game!), and so on.
    - eridius 10y ago
      If you're using a proper type-safe compiled language then most "subtle" breaking changes can't possibly be missed because your code won't compile anymore (assuming you used that API to begin with). You don't need a major version number to call attention to the fact that one parameter of one method changed from a boolean flag to a set of options, anyone who's using that method will find that out pretty quickly. The main reason semver is done the way it is is so you can do things like have package managers automatically pick the latest compatible version, since incompatibilities are denoted by the major version number. That's why I'd prefer major.breaking.minor.patch, because you can still have the package manager automatically detect compatible versions, but you don't end up in the crazy land of releasing a library at v27.
bronson 10y ago
> when you're simply introducing breaking changes (but doesn't qualify as a "significant" release). I can't picture this. Breaking changes are always significant, aren't they? Got an example?
- eridius 10y ago
  If I'm writing a library, and I want to make a relatively minor breaking change to one function (e.g. changing the type of a parameter), that's not a significant change to the whole library, but it is a breaking change and semver demands that I bump the major version number.
  - prodigal_erik 10y ago
    Library users expect breaking changes to be rare and have a damn good reason. What you're describing is deprecation without any warning period ("this stuff will go away in the next major release").
  - vilya 10y ago
    My opinion, as someone whose code got broken by a library micro version update just yesterday, is that the responsible thing to do is add a new function with the new args instead of changing the old one. Change the implementation of the old one so it calls through to the new one with suitable parameter values & and mark the old version as deprecated, but please don't remove it until the next major release!
    - eridius 10y ago
      That's what I do in most cases. But sometimes there's just no option. The particular case that I was referring to when I said I decided to put off changes because I didn't want to bump the version number was actually a stylistic change, renaming a method from `parse(with:)` to `parse(using:)`, in order to better match the Swift 3 naming conventions. Normally I would have just marked the old method as deprecated, except a compiler bug means that if I do so, any code using trailing-closure syntax fails to compile (https://bugs.swift.org/browse/SR-3227 https://bugs.swift.org/browse/SR-3227). So it's literally impossible for me to rename this method in this manner without deleting the old method entirely (which is a breaking change). But I just bumped the major version number recently when Swift 3 was released, and I didn't want to bump it again shortly afterwards just because I didn't consider this method name during the Swift 2->3 migration.
awj 10y ago
> I've actually put off doing breaking changes simply because I didn't want to bump the major version number That's kind of the point though, right. As an API consumer/library user breaking changes are a pain in the ass. A library that rapidly issues breaking changes is one that is just plain difficult to use. Part of the goal with semantic versioning is to push authors to slow down on that and respect the commitments of their users. Also, another thought here is that if you're hitting that many breaking changes that quickly, you possibly went 1.0 too early. > where the first component is for "significant" releases, and the second component is what you use when you're simply introducing breaking changes From a user's point of view, a breaking change is a significant release. It means I can't just hit update and get bug fixes (hopefully) for no effort. I have to investigate changes and test everything to make sure my software will still work.
- Xixi 10y ago
  There's a difference between a major upgrade that breaks nearly everything (like Angular to Angular2) and a smaller but necessary change in a couple of the many functions of an API. So I think there is a point for a major.breaking.minor.patch versioning, depending on the amount of work necessary when bumping major vs breaking. Major would be for rewrites: (almost) a new product, but with the same name for brand recognition.
  - user5994461 10y ago
    > a smaller but necessary change in a couple of the many functions of an API. You can do that as much as you want in version 0.x.x Get to v1 when you figured out the API and it is stable.
    - lilyball 10y ago
      You can only do that once. Once you hit v1, if you introduce new APIs later, there's no "grace period" to make small breaking changes to those APIs. In my case, the library that I avoided making breaking changes to because I didn't want to bump the major version was already on v2, and I didn't want to make it v3 after just a few weeks at v2.
serge2k 10y ago
> I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number Get over it? It's a number. If you want to base it off a consistent semantic reasoning then do so. Otherwise don't do it at all.
malka 10y ago
Cant you just deprecate the Old function, and remove it upon change ? If you mean 'keep bad behavior intact' (ie maintain bugs, that why you should have a spécification. 'the implémentation is the spécification' is very bad imo
erlehmann_ 10y ago
> I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. From your point of view, the problem is something inherent to semantic versioning. From my point of view, the problem is inherent to your behaviour – if you really want to do “several breaking releases one after another”, why hide it from users?
- eridius 10y ago
  I'm not trying to hide it, but the problem is there's no way to communicate "this is a breaking change, but it's not a particularly large or important change", i.e. users don't have to be prepared to learn a bunch of stuff when upgrading.
  - Anchor 10y ago
    I thought change logs served this purpose quite nicely. Every time there is a breaking change, the user needs to check the change log anyway. If there are only some small breaking changes, they are only pleasantly surprised.
taneq 10y ago
> it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that Well how about stopping to think about your API instead of firing off several breaking changes in short succession? The problem here is lack of commitment to a stable API, not the versioning scheme.
Sean1708 10y ago
I get why you feel like that, I really do, but it all seems a bit hand wavey to me. 99% of the time with semver you can unambiguously tell whether it should be a major, minor, or patch bump (of course there are edge cases though).

humanrebar 10y ago

> major.breaking.minor.patch That's the same thing as projectName.major.minor.patch in some respects. You could just rebrand the project if it's a completely different direction. There's not a technical reason to keep the name, just a marketing/political/organizational reason.

thomaslee 10y ago
Exactly. You can keep the brand while still communicating the fact it's an overhaul.
eridius 10y ago
A significant release does not mean it's a completely different direction. It just means that it's significant in some sense.

cbdfghh 10y ago

> I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number, but I don't like that either. When you're doing backend/API things (where breaking changes matter), I sure hope you think a million times before making breaking changes. Can you imagine if someone had to go through millions of lines of his code to make sure nothing broke, then, a week later, you broke his code again?

thomaslee 10y ago
I'm not the parent, but I sort of like the idea at first glance. I mean, it's a fine line: if I have "v1.0.0" and I break one API in one module, I'm compelled to release "v2.0.0" even though v2.0.0 is otherwise entirely compatible with v1 -- it's not as big of an upgrade as the version numbering system would imply. But if I go and drastically change things in a way likely to impact many users, that gets a brand new version number too. So v1.0.0 -> v2.0.0 only really communicates "something might break". The scheme proposed by the parent would be able to communicate "expect many things to break because I refactored the heck out of stuff to fix some long-standing design deficiencies" -- though admittedly when to bump that first version number is likely to be a subjective topic. :) Perhaps this isn't as valuable as it seems at a first glance, but if anybody's tried something like this I for one would be interested to hear about it.
- humanrebar 10y ago
  The point of making backwards compatibility the first number is because the subtle changes need attention drawn to them. There's little risk of people accidentally using things in a broken way when projects are renamed. It's about clarity of technical communication. There are lots of ways to communicate big direction changes, including changing the look and feel of something, adding code words (WD Caviar Green), putting out a big publicity push (v32 is a whole new game!), and so on.
  - eridius 10y ago
    If you're using a proper type-safe compiled language then most "subtle" breaking changes can't possibly be missed because your code won't compile anymore (assuming you used that API to begin with). You don't need a major version number to call attention to the fact that one parameter of one method changed from a boolean flag to a set of options, anyone who's using that method will find that out pretty quickly. The main reason semver is done the way it is is so you can do things like have package managers automatically pick the latest compatible version, since incompatibilities are denoted by the major version number. That's why I'd prefer major.breaking.minor.patch, because you can still have the package manager automatically detect compatible versions, but you don't end up in the crazy land of releasing a library at v27.

bronson 10y ago

> when you're simply introducing breaking changes (but doesn't qualify as a "significant" release). I can't picture this. Breaking changes are always significant, aren't they? Got an example?

eridius 10y ago
If I'm writing a library, and I want to make a relatively minor breaking change to one function (e.g. changing the type of a parameter), that's not a significant change to the whole library, but it is a breaking change and semver demands that I bump the major version number.
- prodigal_erik 10y ago
  Library users expect breaking changes to be rare and have a damn good reason. What you're describing is deprecation without any warning period ("this stuff will go away in the next major release").
- vilya 10y ago
  My opinion, as someone whose code got broken by a library micro version update just yesterday, is that the responsible thing to do is add a new function with the new args instead of changing the old one. Change the implementation of the old one so it calls through to the new one with suitable parameter values & and mark the old version as deprecated, but please don't remove it until the next major release!
  - eridius 10y ago
    That's what I do in most cases. But sometimes there's just no option. The particular case that I was referring to when I said I decided to put off changes because I didn't want to bump the version number was actually a stylistic change, renaming a method from `parse(with:)` to `parse(using:)`, in order to better match the Swift 3 naming conventions. Normally I would have just marked the old method as deprecated, except a compiler bug means that if I do so, any code using trailing-closure syntax fails to compile (https://bugs.swift.org/browse/SR-3227 https://bugs.swift.org/browse/SR-3227). So it's literally impossible for me to rename this method in this manner without deleting the old method entirely (which is a breaking change). But I just bumped the major version number recently when Swift 3 was released, and I didn't want to bump it again shortly afterwards just because I didn't consider this method name during the Swift 2->3 migration.

awj 10y ago

> I've actually put off doing breaking changes simply because I didn't want to bump the major version number That's kind of the point though, right. As an API consumer/library user breaking changes are a pain in the ass. A library that rapidly issues breaking changes is one that is just plain difficult to use. Part of the goal with semantic versioning is to push authors to slow down on that and respect the commitments of their users. Also, another thought here is that if you're hitting that many breaking changes that quickly, you possibly went 1.0 too early. > where the first component is for "significant" releases, and the second component is what you use when you're simply introducing breaking changes From a user's point of view, a breaking change is a significant release. It means I can't just hit update and get bug fixes (hopefully) for no effort. I have to investigate changes and test everything to make sure my software will still work.

Xixi 10y ago
There's a difference between a major upgrade that breaks nearly everything (like Angular to Angular2) and a smaller but necessary change in a couple of the many functions of an API. So I think there is a point for a major.breaking.minor.patch versioning, depending on the amount of work necessary when bumping major vs breaking. Major would be for rewrites: (almost) a new product, but with the same name for brand recognition.
- user5994461 10y ago
  > a smaller but necessary change in a couple of the many functions of an API. You can do that as much as you want in version 0.x.x Get to v1 when you figured out the API and it is stable.
  - lilyball 10y ago
    You can only do that once. Once you hit v1, if you introduce new APIs later, there's no "grace period" to make small breaking changes to those APIs. In my case, the library that I avoided making breaking changes to because I didn't want to bump the major version was already on v2, and I didn't want to make it v3 after just a few weeks at v2.

serge2k 10y ago

> I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number Get over it? It's a number. If you want to base it off a consistent semantic reasoning then do so. Otherwise don't do it at all.

malka 10y ago

Cant you just deprecate the Old function, and remove it upon change ? If you mean 'keep bad behavior intact' (ie maintain bugs, that why you should have a spécification. 'the implémentation is the spécification' is very bad imo

erlehmann_ 10y ago

> I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. From your point of view, the problem is something inherent to semantic versioning. From my point of view, the problem is inherent to your behaviour – if you really want to do “several breaking releases one after another”, why hide it from users?

eridius 10y ago
I'm not trying to hide it, but the problem is there's no way to communicate "this is a breaking change, but it's not a particularly large or important change", i.e. users don't have to be prepared to learn a bunch of stuff when upgrading.
- Anchor 10y ago
  I thought change logs served this purpose quite nicely. Every time there is a breaking change, the user needs to check the change log anyway. If there are only some small breaking changes, they are only pleasantly surprised.

taneq 10y ago

> it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that Well how about stopping to think about your API instead of firing off several breaking changes in short succession? The problem here is lack of commitment to a stable API, not the versioning scheme.

Sean1708 10y ago

I get why you feel like that, I really do, but it all seems a bit hand wavey to me. 99% of the time with semver you can unambiguously tell whether it should be a major, minor, or patch bump (of course there are edge cases though).