4 ms·

> If you're introducing breaking changes once per month, then your library really isn't ready. The whole software industry moved away from waterfall to agile b

by barumi 6y ago

> If you're introducing breaking changes once per month, then your library really isn't ready. The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. I would disagree, for example, that Python3 is not ready just because they're introduced backward incompatible changes in some minor releases.

tick_tock_tick 6y ago
I mean python is basically the prime example of how to poorly manage version upgrades with their failure of 2 => 3.
- bigiain 6y ago
  They were just desperate to do a better job of screwing up than Perl with it's 5 => 6 updates... <grin>
  - masklinn 6y ago
    As we can see from the Perl ecosystem having completely moved over to the extent that Perl 5 is now out of support while Python is still mired in the update.
    - takeda 6y ago
      That's funny, because I see the opposite. Perl 6 was a failure that had to be spun into a separate language and people stayed with perl 5, recently work on perl 7 started, but as far as I know perl 5 is still the version in use, recently FreeBSD forced me to update perl to version 5.32. Regarding Python, I no longer see 2.7 in the wild (I have no doubt it is still in some places) all projects I'm working on are in Python 3. AWS Lambda supports 3.8 (which is the latest stable version), Ubuntu comes with 3 installed by default. FreeBSD set 3.7 as default, depreciated and will remove 2.7 completely by the end of this year. Many Python 3 packages were released as python 3 only, the packages that that previously supported 2 dropped their support. Currently running 2.7 is a liability. Not as much that it is EOL and there are no security fixes anymore, but also packages dropping support (which is IMO a bigger deal).
      - masklinn 6y ago
        Yes my comment was ironic.
        takeda 6y ago
        ah, feeling dumb now :)
- barumi 6y ago
  Can you provide a single example that supports your thesis that migration from Python 2 to 3 was poorly managed semver-wise? If anything, Python is chastised for having maintained two major versions in parallel without giving any compelling reason to force major rewrites on the while ecosystem.
brabel 6y ago
> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge That's completely unrelated to library versioning. The software industry that I work at absolutely relies on library authors to diligently introduce breaking changes only in rare occasions, and preferably using semver to the extent possible. If you can't guarantee your library will be kept up-to-date with bug and security fixes, without me having to re-write my application on minor library updates because you decided to change your API to make it prettier, then I most certainly won't be using your library (indeed, I have removed dependencies from projects I worked on for this reason).
- nemothekid 6y ago
  >re-write my application on minor library updates This is the tension of semver - a minor library update might include a breaking change, but that doesn't mean you have to rewrite your application. For example, lets say I have a library that returned an int32 in a single function that would silently corrupt your data, but now has to return an int64. The right thing to do would be to issue a major upgrade where the function returns an int64. If you never used this function you wouldn't have to rewrite your application. Major updates in semver only mean backwards compatibility is broken, it doesn't mean it's am whole new api. To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder.
  - Skinney 6y ago
    > To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder. Then make a new function within the same folder that works in a new way. If necessary, mark the old function as deprecated. An exception can be made if the function never worked to begin with, but that should really have been cought by tests or people using a pre-release version of the library.
curryst 6y ago
> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. There's also an insidious side effect that people tend to think of the more common semver of features than strict semver, and they associate versions with progress and effort. You could easily get to version 50.0.0 just sorting out finishing touches on the API with strict semver if you don't have good communication with the customer. Some enterprising middle manager will start asking you've spent 50 major versions worth of effort on this library or app. As a result of those effects and the unequal application of semver, I usually encourage people at work to choose other versioning schemes. Without strictly enforcing semver, there's really not a huge advantage to semver over a plain incrementing version. Incrementing versions also have the nifty feature of making it trivial to see how many versions behind you are. Or some people go with timestamped versions, which tells you how old your version is.

by barumi 6y ago

tick_tock_tick 6y ago

I mean python is basically the prime example of how to poorly manage version upgrades with their failure of 2 => 3.

bigiain 6y ago
They were just desperate to do a better job of screwing up than Perl with it's 5 => 6 updates... <grin>
- masklinn 6y ago
  As we can see from the Perl ecosystem having completely moved over to the extent that Perl 5 is now out of support while Python is still mired in the update.
  - takeda 6y ago
    That's funny, because I see the opposite. Perl 6 was a failure that had to be spun into a separate language and people stayed with perl 5, recently work on perl 7 started, but as far as I know perl 5 is still the version in use, recently FreeBSD forced me to update perl to version 5.32. Regarding Python, I no longer see 2.7 in the wild (I have no doubt it is still in some places) all projects I'm working on are in Python 3. AWS Lambda supports 3.8 (which is the latest stable version), Ubuntu comes with 3 installed by default. FreeBSD set 3.7 as default, depreciated and will remove 2.7 completely by the end of this year. Many Python 3 packages were released as python 3 only, the packages that that previously supported 2 dropped their support. Currently running 2.7 is a liability. Not as much that it is EOL and there are no security fixes anymore, but also packages dropping support (which is IMO a bigger deal).
    - masklinn 6y ago
      Yes my comment was ironic.
      - takeda 6y ago
        ah, feeling dumb now :)
barumi 6y ago
Can you provide a single example that supports your thesis that migration from Python 2 to 3 was poorly managed semver-wise? If anything, Python is chastised for having maintained two major versions in parallel without giving any compelling reason to force major rewrites on the while ecosystem.

brabel 6y ago

> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge That's completely unrelated to library versioning. The software industry that I work at absolutely relies on library authors to diligently introduce breaking changes only in rare occasions, and preferably using semver to the extent possible. If you can't guarantee your library will be kept up-to-date with bug and security fixes, without me having to re-write my application on minor library updates because you decided to change your API to make it prettier, then I most certainly won't be using your library (indeed, I have removed dependencies from projects I worked on for this reason).

nemothekid 6y ago
>re-write my application on minor library updates This is the tension of semver - a minor library update might include a breaking change, but that doesn't mean you have to rewrite your application. For example, lets say I have a library that returned an int32 in a single function that would silently corrupt your data, but now has to return an int64. The right thing to do would be to issue a major upgrade where the function returns an int64. If you never used this function you wouldn't have to rewrite your application. Major updates in semver only mean backwards compatibility is broken, it doesn't mean it's am whole new api. To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder.
- Skinney 6y ago
  > To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder. Then make a new function within the same folder that works in a new way. If necessary, mark the old function as deprecated. An exception can be made if the function never worked to begin with, but that should really have been cought by tests or people using a pre-release version of the library.

curryst 6y ago

> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. There's also an insidious side effect that people tend to think of the more common semver of features than strict semver, and they associate versions with progress and effort. You could easily get to version 50.0.0 just sorting out finishing touches on the API with strict semver if you don't have good communication with the customer. Some enterprising middle manager will start asking you've spent 50 major versions worth of effort on this library or app. As a result of those effects and the unequal application of semver, I usually encourage people at work to choose other versioning schemes. Without strictly enforcing semver, there's really not a huge advantage to semver over a plain incrementing version. Incrementing versions also have the nifty feature of making it trivial to see how many versions behind you are. Or some people go with timestamped versions, which tells you how old your version is.