Konstantin,
On 7/21/22 09:56, Konstantin Kolinko wrote:
чт, 21 июл. 2022 г. в 15:23, Christopher Schultz <ch...@christopherschultz.net>:
Nemo, Mark,
On 7/21/22 04:06, Mark Thomas wrote:
On 21/07/2022 07:06, Nemo wrote:
<snip/>
Generally, I'd strongly discourage anyone from assuming that GitHub tag
== ASF release.
I generally agree with Mark, here, with one caveat:
It would be very easy for our release tags to have multiple names. We
can tag the release as x.y.z-rc, go through the voting process, etc. and
then alias the tag to x.y.z and leave both of them there for posterity.
That way, automated tools can just ignore all tags ending in -rc and
when the /real/ x.y.z tag is available, that can trigger .... whatever
process they want to follow.
1. I see no need to change the release process to be more complex,
but it is up to release managers to decide if they want additional work.
Changing the release process as Christopher proposes is doable for Tomcat,
as long as it is built with Apache Ant,
but it will result in lingering *-rc tags in the repository.
Those add little value, but add some notable clutter.
Meh. No more than having a large number of releases.
Changing the process for the Tomcat Migration Tool for Jakarta EE
that is built with Apache Maven would be harder,
as it contradicts with how Maven Release Plugin works.
Personally I think that a tool that relies on GitHub tags is just broken.
+1
Anyone can tag anything at any time for any reason. A new tag == trigger
a build pipeline that causes new releases of downstream projects to be
built and released? Wow. What happens if the release vote doesn't pass
and we remove the tag?
It seems very fragile to me.
2. If one wants to track the release date:
When a release of Apache Tomcat is published,
a) the DOAP file is updated,
https://tomcat.apache.org/doap_Tomcat.rdf
b) the release is published to dist.apache.org and becomes available via CDN
c) artifacts are published to the Maven Central
*This* should probably be the trigger that causes all that downstream
stuff to occur. We won't upload anything to Maven Central that isn't
official.
d) a release announcement is sent to annou...@tomcat.apache.org and to
some other mailing lists.
An automated tool may track any one of those. If one wants a release
date, then a), c) and b) are available. The DOAP file (a)) is designed
to be used by tools, but is less reliable than c) and b).
An announcement at the front page of tomcat.apache.org and a changelog
file also have the date.
3. GitHub itself makes a difference between "tags" and "releases".
For Apache Tomcat project the GitHub is essentially a mirror. It
mirrors the tags from the official ASF git repository.
We do not publish "releases" there.
https://github.com/apache/tomcat/releases
I don't know what it would take to "release" on GH. If it's not too much
work, I'd be willing to do it, particularly if it can be mostly scripted.
4. BTW I frequently see that in other projects a build date (signature
date in signed Windows installers) and announcement date are
different.
E.g. OpenJDK.
When I used builds from Oracle, there could be 1-2 week difference
between apparent build date and the official announcement.
E.g. Mozilla Firefox:
- https://www.mozilla.org/en-US/firefox/102.0.1/releasenotes/
says Firefox 102.0.1 was released on July 6, 2022 and that is the
official date.
- The digital signature of "Firefox Setup 102.0.1.exe" installer is from July 5.
- Files at https://ftp.mozilla.org/pub/firefox/releases/102.0.1/ are of July 5.
For Firefox 101.0 the difference is more noticeable:
May 31 (the official date) vs May 27 (signature) vs May 30 (files).
Thanks for your thoughts, K.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
