-
Notifications
You must be signed in to change notification settings - Fork 949
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
[suggestion] Label only highest tag as latest release #16297
Comments
Hi @pataxis Thanks for your feedback. I think you are right, and it doesn't make sense to tag all releases as latest, I think you might have hit the issue with the latest We'll have a look, and we will probably try your suggestion, keep tuned :) |
There is a problem, the library we are using to create the releases in Github doesn't have support for not making a release the latest, it just merged the feature in PyGithub/PyGithub#2888, but not yet released. |
@czoido wdyt? As the Conan 1.X releases will be less frequent, maybe we can just recall to manually change the latest in https://github.com/conan-io/conan/releases when we release a 1.X? |
Yes, I think that's the best option because we already tried to fix this in the past but we faced the issue with the library. Now that we are releasing 1.X from time to time I'll add some warning in the release pipeline so we don't forget next time. |
Thanks @czoido, let's do that. Closing this ticket then, thanks for the feedback! |
What is your suggestion?
In our CI we download the Conan Debian package from the assets of the latest release via the GitHub API to always stay update.
The problem
We noticed a strange behaviour where downloads often, but not always, failed at build time on downloading Conan Debian package.
I thought it was only a matter of hitting the Rate Limit occasionally, but now that we worked around that issue, we found another source to the shakiness.
The problem is that Conan always mark any tag as the latest release, no matter if it's major 1 or a major 2 release. This makes the latest release feature of GitHub API useless.
Workaround
I have updated our CI to:
jq -r .assets[].browser_download_url
andgrep -E https://github.com.*.deb
Suggestion
It would make more sense if you only set the latest label on releases of the highest major, which now is 2.
Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: