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

How to correctly manage Release Candidates releases #211

Open
ranshid opened this issue Feb 19, 2025 · 1 comment
Open

How to correctly manage Release Candidates releases #211

ranshid opened this issue Feb 19, 2025 · 1 comment

Comments

@ranshid
Copy link
Member

ranshid commented Feb 19, 2025

Currently after 8.1.0-rc1 release we have the following presented on the webpage:

  1. On the download page we have the latest GA release reported as the latest release (I think we should place some indication like "Latest stable release") and no RCs are reported there
  2. On the release page we have the release candidate presented, but only in case there is not yet any "stable"/GA release. So for 8.1.0-rc1 is currently shows there.
  3. the url for the release download is currently made up of --. So, for example, 8.1.0-rc1 has the url: https://valkey.io/download/releases/v8-1-0/ which does NOT include the 'rcN' tag. Thios has the advantage that users can continue using the link and have it "automatically" updated when we issue a new RC, but users also lose the ability to download old RCs.

This raises the following quesitons:

  1. should we explicitly indicate Release candidate on RCs release download pages? (currently the only indication is that the download ref name is 8.1.0-rc1 )
  2. should we keep a single url link for each release (like today)? I thin it might make sense to have a dedicated link for each RC but it means we will have to persist them in our web repo and not just "remove" them after a new RC is released.

I would suggest the following:

  1. We should manage and persist RC releases download url links.
  2. We should keep RC links on the release page. users should be able to download the specific RC later in orer to compare changes and reproduce bug fixes IMO.
  3. We should explicitly state on the download page that this is the latest STABLE release.
@madolson
Copy link
Member

I think your suggestions are all reasonable.

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

No branches or pull requests

2 participants