4 ms·

I feel like this is meant to be satire, but I wonder if there's some truth to it: Usually updates to a "major" version come with an implied assumption that ther

by allo37 5y ago

I feel like this is meant to be satire, but I wonder if there's some truth to it: Usually updates to a "major" version come with an implied assumption that there won't be any breaking API changes. Maybe being perpetually at 0 gives you the "It's beta software, you need to update bro" defence against maintaining a stable API, and all the extra overhead that comes with it.

a3w 5y ago
Why not release 2.x after a month, breaking the API again? Heck, why not next day when you find out that all APIs suck.
- allo37 5y ago
  Because you'll still have customers on version 1.x, who will still expect support and refuse to update for <reasons>. It's not that it's impossible but it imposes an additional burden on the development team, which affects how fast you can add features.
  - mahkoh 5y ago
    That's why our team at GigaCorp has switched to not using minor version numbers. In the past we had customers who expected continuous security updates without updates to the minor version due to some internal policy. All of our new products use 0.0.x versioning where x is incremented for each release. This way we can easily push out new releases and our customers have no reason to delay updates.
  - remram 5y ago
    But that's the same with 0.1 and 0.2. You will still have users in 0.1 who will expect support and refuse to update.
    - allo37 5y ago
      Unfortunately irrationally difficult customers are a bit like death and taxes in that sense, but "We have a new version with some minor fixes that you can use" is generally an easier sell than "We have a new version with some major changes that will completely disrupt your workflow".
      - remram 5y ago
        This is true no matter what you name your versions, I don't know what you are saying.
iainmerrick 5y ago
I feel like this is meant to be satire, but I wonder if there's some truth to it Yes and yes. But isn’t that kind of the point of good satire?
UglyToad 5y ago
Yes. From my perspective one benefit of 0 major version in 1-person OSS projects is it gives a clear signal that "yes this code is available for you, but no I'm not an enterprise support solution, I'll do what seems useful/relevant to me when I have time and when it feels relevant". That doesn't mean intentionally breaking backwards compatibility but also this isn't my paid day job so I might do it and I'm not going to spend my evenings compiling release notes / migration guides for free. In this way it's an effective anti-big-corp shield since a lot of enterprises have dumb rules about using beta/alpha versions. I think it's a strong signal where people can't just use a beta or pre-release version of some code that they're a) not auditing their dependencies and b) probably work somewhere that has the money to pay for that level of service but just want you to do it for free.
remram 5y ago
There won't be any breaking API change until the next major version. Nothing in semvet prevents you from having releases 1, 2, 3, 4 instead of 0.1, 0.2, 0.3, 0.4. At some point you can just drop the zero and carry on, it's false to say that you can't make breaking changes after 1.0.

by allo37 5y ago

a3w 5y ago

Why not release 2.x after a month, breaking the API again? Heck, why not next day when you find out that all APIs suck.

allo37 5y ago
Because you'll still have customers on version 1.x, who will still expect support and refuse to update for <reasons>. It's not that it's impossible but it imposes an additional burden on the development team, which affects how fast you can add features.
- mahkoh 5y ago
  That's why our team at GigaCorp has switched to not using minor version numbers. In the past we had customers who expected continuous security updates without updates to the minor version due to some internal policy. All of our new products use 0.0.x versioning where x is incremented for each release. This way we can easily push out new releases and our customers have no reason to delay updates.
- remram 5y ago
  But that's the same with 0.1 and 0.2. You will still have users in 0.1 who will expect support and refuse to update.
  - allo37 5y ago
    Unfortunately irrationally difficult customers are a bit like death and taxes in that sense, but "We have a new version with some minor fixes that you can use" is generally an easier sell than "We have a new version with some major changes that will completely disrupt your workflow".
    - remram 5y ago
      This is true no matter what you name your versions, I don't know what you are saying.

iainmerrick 5y ago

I feel like this is meant to be satire, but I wonder if there's some truth to it Yes and yes. But isn’t that kind of the point of good satire?

UglyToad 5y ago

Yes. From my perspective one benefit of 0 major version in 1-person OSS projects is it gives a clear signal that "yes this code is available for you, but no I'm not an enterprise support solution, I'll do what seems useful/relevant to me when I have time and when it feels relevant". That doesn't mean intentionally breaking backwards compatibility but also this isn't my paid day job so I might do it and I'm not going to spend my evenings compiling release notes / migration guides for free. In this way it's an effective anti-big-corp shield since a lot of enterprises have dumb rules about using beta/alpha versions. I think it's a strong signal where people can't just use a beta or pre-release version of some code that they're a) not auditing their dependencies and b) probably work somewhere that has the money to pay for that level of service but just want you to do it for free.

remram 5y ago

There won't be any breaking API change until the next major version. Nothing in semvet prevents you from having releases 1, 2, 3, 4 instead of 0.1, 0.2, 0.3, 0.4. At some point you can just drop the zero and carry on, it's false to say that you can't make breaking changes after 1.0.