Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.16 doesn't respect semver conventions - it should #1990

Closed
jcdevguru opened this issue Feb 26, 2025 · 4 comments
Closed

0.16 doesn't respect semver conventions - it should #1990

jcdevguru opened this issue Feb 26, 2025 · 4 comments

Comments

@jcdevguru
Copy link

jcdevguru commented Feb 26, 2025

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
Copy link

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

@Stratus3D
Copy link
Member

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

@jcampbell-mb
Copy link

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants