Add Homebrew support

[helpermethod]

• add JReleaser Templates for the Homebrew Tap Formula and README
• enable Homebrew packager in JReleaser's configuration
• create a Personal Access Token with repo permissions to use as JRELEASER_HOMEBREW_GITHUB_TOKEN
• add sdkman_selfupdate_feature flag to disable selfupdate functionality (including auto_update)
• keep sdkman_selfupdate_enable flag for backwards-compatibility
• introduce sdkman_auto_update flag for enabling/disabling auto_update (replaces sdkman_selfupdate_enable)
• add tests to make sure that any combination of old / new flags works as expected

[aalmiray]

Watch out for jreleaser/jreleaser#702 when upgrading to JReleaser v1.0.0-M2 or later. Templates will use {{distributionExecutableUnix}} instead of {{distributionExecutable}}.

[helpermethod]

@marc0der Removing the sdkman-selfupdate.sh file as a post-install step is probably a little bit extreme but simplifies certain things. I'm still not sure if this is the best way 😆.

Alternatively we could introduce another flag for disabling the selfupdate functionality, and hope that no one switches it on.

[helpermethod]

Hi @marc0der, I've added some tests to make sure that the old behaviour doesn't break.

[marc0der]

Looks good so far. We shouldn't forget to add the new config to the sdkman-hooks service as mentioned.

[helpermethod]

@marc0der With the hook updates promoted to stable, I wonder if

# Attempt upgrade after all is done
if [[ "$COMMAND" != "selfupdate" && "$sdkman_selfupdate_feature" == "true" && ("$sdkman_auto_update" == "true" || "$sdkman_selfupdate_enable" == "true") ]]; then
	__sdkman_auto_update "$SDKMAN_REMOTE_VERSION" "$SDKMAN_VERSION"
fi

the sdkman_selfupdate_enable check here is actually needed? I guess the selfupdate hook will take care of replacing it, right?

Would be nice if we could get rid of that OR expression.

[marc0der]

@helpermethod You are right. The selfupdate should take care of it, provided we deploy the hooks before the CLI. That said, I suggest leaving it in until both have been deployed, then removing it in a tiny follow-up PR once the dust has settled.

[helpermethod]

Too late, already removed it 😂

[marc0der]

@helpermethod You are too fast 😆 You probably need to update the SdkmanBashEnvBuilder and SelfupdateSpec too which still refer to the old variable.

[helpermethod]

Removed the selfupdate_enable flag from the data table.

[helpermethod]

Oh, and before we finally do the release I need to drop the old SDKMAN! Homebrew repository.

[marc0der]

Okay, are you happy for me to merge that so we can test it in the beta channel?

[helpermethod]

Let's go!

[felipecrs]

This was a breaking change for me, sad it wasn't tagged as one. I think it should be avoided to perform breaking changes without bumping the major version (like from 5 to 6).

felipecrs/dotfiles@5ba2f2b

[helpermethod]

Sorry to hear 😥!

The sdk selfupdate command will automatically perform the migration, so for most users it should be a backwards-compatible change.

That's why we didn't bump the major version.

[felipecrs]

That's ok, it's not the first time anyway.

#1069 kind of prevents it (in the sense that if someone didn't touch the default configuration, it will be handled by the migration). But only in that case.

[felipecrs]

By the way, docs are missing the new sdkman_auto_update:

https://sdkman.io/usage#config