add stable.txt

[rolinh]

Add stable.txt, a file in the master branch that always points to the
latest stable release of Cilium. This file can be used as a reference by
tools such as the Cilium CLI to get the latest stable release version.
This pattern and file is already applied to the Hubble CLI repository.

Ultimately, this new file will allow the Cilium CLI to always install
the latest version of Cilium, as initially planned, instead of the
version hardcoded in the CLI binary.

[qmonnet]

The current version for the master branch is in VERSION, should the new file be named STABLE for consistency?

[nbusseneau]

LGTM, not sure if we want to leave it as a manual step in the release process or automate but in either case this will help cilium/cilium-cli#272.

@aanm While we're at it, should we also update step 15 so that quay.io stable tag do not get forgotten on next release?

[aanm]

Sorry for taking too much time reviewing the PR. There was a discussion on slack where I've proposed the following:

having a stable.txt will kind of not work well when we branch off, i.e., is one more thing that we need to take care of when doing releases. Can't we use the versions available in our helm repositories and use them instead? For example if I type, helm search repo cilium/cilium --versions it shows me all versions available.

I meant that stable.txt will also be available in stable branches.

Would that be reasonable?

[aanm]

Also adding @joestringer take a look as well

[joestringer]

I like the helm proposal at first glance, for what it's worth. Seems like less work on the release management side, but I guess maybe requires more processing on the external component to understand what the stable version is since they would have to query Helm and process its output.

Another option would actually be to just add the stable.txt into the github.com/cilium/charts repo, then we don't have the question of how to deal with Cilium branching.

[rolinh]

I meant that stable.txt will also be available in stable branches.

I don't think this is required and thus unnecessary. Only the stable.txt in the master branch needs to be updated (and the file could be deleted when branching out a minor version (e.g. v1.11)).

Another option would actually be to just add the stable.txt into the github.com/cilium/charts repo, then we don't have the question of how to deal with Cilium branching.

I don't think we have this question here either. The only requirement is to be able to retrieve the very latest stable release version, not every supported stable release versions.

[joestringer]

and the file could be deleted when branching out a minor version (e.g. v1.11).

This seems reasonable, if that's the case can we add the step to Documentation/contributing/release/feature.rst in this PR? That's where we track the tasks for a feature/minor version release.

I'd also love for the step for new stable/micro release to be integrated into contrib/release/bump-readme.sh rather than just added as a step in the docs, since that script currently handles 100% of the master changes for any given release, and is ready to be integrated into automation workflows; adding another step in the docs moves us back away from that. If that change seems straightforward to you, please propose it in this PR; I'll review & we can test it out next time we do a release. If it seems more complicated then I guess I'll figure it out next release.

[rolinh]

I'd also love for the step for new stable/micro release to be integrated into contrib/release/bump-readme.sh rather than just added as a step in the docs

Makes sense. How does one know about the latest stable release though? Should it be a parameter to pass to the script?

[joestringer]

Makes sense. How does one know about the latest stable release though? Should it be a parameter to pass to the script?

I guess depends on how robust we want to make it. The script currently just greps for General Announcement in the README.rst and then iterates through each of the release series, then uses git describe --tags for the minor version to figure out the most recent micro release.

Seems like for the first match of General Announcement we can also echo the discovered micro release version to the stable.txt. It's unlikely we'll change the ordering of the releases to put the most recent minor release lower in the list. Nice thing about this would be that we still don't need to provide any parameters, you just run the script and it figures everything out by itself.

[rolinh]

Seems like for the first match of General Announcement we can also echo the discovered micro release version to the stable.txt. It's unlikely we'll change the ordering of the releases to put the most recent minor release lower in the list.

I implemented this suggested approach. PTAL.

[joestringer]

Thanks for fixing up the script, LGTM.