sbp commented on issue #386: URL: https://github.com/apache/tooling-trusted-releases/issues/386#issuecomment-3607485032
Commit 6265b870c9563557081a7982905456973bbcb62f adds the field documentation: > Enter the version string for this new release. This cannot be changed later, and must be the version of the finished release. ATR generates a unique revision serial number for each voting round, and you can also set your own tag before a vote starts. And the following paragraph on the page to start a release: > Your version number should look like `1.2` or` 1.2.3` etc. and should not include a release candidate, alpha, beta, or milestone portion. Whenever you modify your release files before starting a vote, ATR creates a new revision serial number like 00002 which you can then refer to in the vote announcement email. You can also tag revisions, and either the revision serial number or the tag can be used in the vote announcement email. The tag can e.g. be set to `M1` or `rc1`. Note that Maven `M1` style tagging has historically been a source of confusion, such as in [this note from user Alberto on StackOverflow](https://stackoverflow.com/questions/3687208/what-does-m1-mean-in-a-maven-repository#comment127090486_3687216): > the ASF in the same paragraph of their release policy declare that _releases are packages that have been approved for general public release_, and at the same time state that milestone release _are intended only for bleeding-edge developers_ ... Does the general public consist only of bleeding-edge developers? To disorient a bit more, we find quotes like _**Apache Maven Surefire 3.0.0-M6** This is the current stable version of Apache Maven Surefire._ (from [maven.apache.org/surefire/download.cgi](https://maven.apache.org/surefire/download.cgi), as seen on the 2022-04-19) 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. -- 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]
