fix!: remove use_release_candidate option

[jthegedus]

Summary

Now we are using release-please & GitHub Releases to manage our changelog generation and release pipeline we're no longer using release candidates (as they were originally intended) with asdf core.

People who wish to test the latest code should use HEAD via asdf update --head.

If HEAD is too unstable for people and they want an RC equivalent, then we have two options:

1. we can implement asdf update <sha>
2. we can recommend users cd to asdf installation and perform a manual git checkout <sha>

Given no users have raised missing the RC I feel we are safe to go with option 2 here. We can add asdf update <sha> in future if it becomes necessary to do so.

Other Information

This also removes sort_versions from the repository 🎉

Related:

• feat: asdf list commands to sort output by version, not lexical #1428 - we were discussing removing sort_versions which this PR does

Fixes #1515

[jthegedus]

Big question before we merge, is this considered a "breaking change"? I would think yes, as we're changing an external API, though it is only for users to update, but it could be used in a CI pipeline? 🤔

Thoughts @Stratus3D

Edit: I have marked as Breaking with ! in the conventional-commit type. I still wish to get your thoughts.

[Stratus3D]

Is this git rev-list command returning the most recently created tag, or the tag with the highest semantic version?

If this is returning the most recently created tag, we may want to stick with the sort_versions approach here in case we ever tag a new patch version for old minor version of asdf. I know we've not done that thus far, so maybe it's not necessary.

[Stratus3D]

Yeah, looking at this again I'd suggest keeping sort_versions for now. All other changes look good to me.

[jthegedus]

I have a different solution to propose here which would still remove sort_versions, I have just been busy with work so haven't had a chance to write it up. I would like to discuss that alternative before keeping sort_versions

[Stratus3D]

I feel like the old approach with sort_versions was more foolproof, as it always returned the right tag. It seems like the new code could return any tag, regardless of what name the tag was, as long as it was the newest. If someone were to create an rc or beta tag for some reason it'd be recognized as the latest. I know we don't intend to do that anymore, but it might be better to play it safe.

I think getting rid of use_release_candidate is the right choice, other than my concern with sort_versions this looks great!

[jthegedus]

When I created this change I was not considering the scenario where we would manually create rc or beta tags.

I will update this PR with another suggestion.

[Stratus3D]

Big question before we merge, is this considered a "breaking change"?

I guess I never answered your question yesterday. Yes, I'd consider this a breaking change just to be safe.

[jthegedus]

My last push was to just rebase before my new changes. I won't get to proposing my new changes until next week (2nd week April 2023).

The gist of my upcoming changes are:

• prepare
  • detect default branch
  • detect remote
  • git fetch from remote
• asdf update: use GitHub Release to detect "latest" version, then checkout the tag (as we do now)
  • manual GH Releases do NOT default to "latest", that is a checkbox to manually opt-in
  • automated release-please GH Releases will assign "latest"
• asdf update --head: checkout default branch and reset to HEAD (as it does now)
• asdf update <sha|tag>: checkout the specific SHA or Tag

Still working through updating tests cases etc

While certainly more code than what we currently have, I feel this is more straightforward.