sbp opened a new issue, #388: URL: https://github.com/apache/tooling-trusted-releases/issues/388
From a comment I made on #386: > Many of our TLPs have current `M[0-9]+` and `rc[0-9]+` releases. Perhaps we should document and model this situation as encompassing internal (ATR revision or tag) pre-releases and external (`M[0-9]+`, `rc[0-9]+` etc. in the finished release) pre-releases? But [our release policy](https://www.apache.org/legal/release-policy.html) clearly says: > > > **Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages.** [...] **Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package.** > > In bold per the original. This may imply that TLPs have some kind of need that is not covered by the release policy, or that they are unaware of this part of the policy, or that I am misreading the situation. The policy also says: > > > **Release Candidates** are packages that have been proposed for approval as a release but have not yet been approved by the project. > > Only approved packages can have a final release on ATR, so we should probably look for rc, alpha, beta, and milestone tags in submitted revision numbers and disallow or strongly warn the release manager. We allow such tags in filenames because they can be stripped out in the final phase before announcement, as a special case. This is a bit complicated but we thought it was a good compromise. We should clarify which of the _de facto_ or _de jure_ situations needs to be reflected in ATR. Unless we hear to the contrary we will go with the _de jure_ situation and follow the ASF release policy in forbidding version numbers which appear to contain a pre-release component. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
