0.16 doesn't respect semver conventions - it should

[jcdevguru]

Follow conventions when introducing breaking changes

Per my experience and your discussions in your documentation: 0.16 is breaking change from 0.15. This is trouble for software managers that expected adherence to semver connections where only major revisions, as indicated by increments in the first digits, signify a breaking change. In my case, Homebrew just automatically updated from 0.16 to 0.17 since it did not think that only a minor number revision would introduce a breaking change. But because it did, my installation stopped working. You get problems from these incompatibilities:

• asdf.sh was removed, which means the login initialization will fail
• we need an environment variable for ASDF_DATA_DIR - we did not need one before
• we need to set PATH to include the shims directory under $ASDF_DATA_DIR - we did not need that
• we need to run asdf reshim to get previously installed packages working again.

This is all unexpected when you run asdf update.

Describe the proposed solution

I would ask that you release 0.17 version as a 'migration' release that maintains the files and interfaces that were used in 0.15 (without requiring them since 0.16 is already out) - and then have the functionality in 0.17 be under 1.xxx, where you don't need the interfaces.

Describe similar asdf features and why they are not sufficient

Please see above.

Describe other workarounds you've considered

Please see above.

[jmfrancois]

0.x in semver means you do not follow semver
https://semver.org/#spec-item-4

[Stratus3D]

Closing this as duplicate of #1969 #1861 and #1857

[jcampbell-mb]

0.x in semver means you do not follow semver
https://semver.org/#spec-item-4

You are dodging the point.

0.x is for test versions, prior to release. This is not the case here. asdf has been in wide release for years, which means it should have been at least at 1.something. By introducing a breaking change without proper versioning, you broke the software without warning, you have made life problematic for people not expecting it. Keeping the versioning at 0.x is not a free pass to do that. You have a public solution here that you should be maintaining.

Again, you could have set up a migration release and would have done just fine here. Package managers support that and would have applied it automatically. You could have at least made the transition more friendly , e.g., have asdf.sh issue a warning, telling the users what to do (0.17?). Now you have complaints and possibly lost users, which is an issue for your software and is not waived by technicalities in the spec.

[Stratus3D]

asdf has been in wide release for years, which means it should have been at least at 1.something.

No, there is no reason popular software must be 1.x. I have been using various packages with 0.x.x version in critical production systems for years without issue. The only thing 0.x means is that there are could be big breaking changes between versions, so upgrades.

Again, you could have set up a migration release and would have done just fine here. Package managers support that and would have applied it automatically.

A migration guide page was added to the website and linked to in the changelog - https://asdf-vm.com/guide/upgrading-to-v0-16.html

You could have at least made the transition more friendly , e.g., have asdf.sh issue a warning, telling the users what to do (0.17?)

We did that. See #1833

I'm sorry the upgrade process has been painful for you. We worked hard to make this as smooth a process as possible, but migrating a codebase from Bash to Go is never going to be trivial. We don't intend to ever perform a rewrite like this again.