You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Nemo <me...@captnemo.in> on 2022/07/21 06:06:50 UTC
Delay between release tags and announcement
Hi,
Writing this on behalf of the endoflife.date project, where we recently
started tracking tomcat releases and support[0]. To track tomcat
releases automatically, we are tracking the tags on the GitHub
repository[1] which results in this data[2].
I wanted some clarification about the release process, specifically with
regards to tagging new releases. I read through the archives, and
noticed that the 10.0.23 release is still pending a vote, but it is
already tagged:
- https://github.com/apache/tomcat/releases/tag/10.0.23
Arch (and its downstream distros) seems have to have already packaged
this: https://repology.org/project/tomcat/history. Repology is already
marking 10.0.22 as an "outdated" release in this case. A similar delay
happened for 9.0.65 as well, where it was tagged (and released
downstream) before being announced.
I read through the Apache Voting process[3] doc, but it doesn't make a
clarification about when the releases should be tagged.
What happens if a vote doesn't pass or get vetoed - do the tags get deleted?
Perhaps the tagging/voting process should include a rc tag instead of a
release tag, so as to avoid getting released downstream accidentally?
Thanks,
Nemo
(Please keep me in cc for replies)
[0]: https://endoflife.date/tomcat
[1]: https://github.com/apache/tomcat,
https://git.apache.org/repos/asf?p=tomcat.git;a=tags
[2]:
https://github.com/endoflife-date/release-data/blob/main/releases/tomcat.json
[3]: https://apache.org/foundation/voting.html#ReleaseVotes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Delay between release tags and announcement
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 announce@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Delay between release tags and announcement
Posted by Konstantin Kolinko <kn...@gmail.com>.
чт, 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.
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.
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
d) a release announcement is sent to announce@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
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).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Delay between release tags and announcement
Posted by 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/>
>
>> What happens if a vote doesn't pass or get vetoed - do the tags get
>> deleted?
>
> Release votes cannot be vetoed.
>
> If a release vote doesn't pass, that release doesn't happen. In Tomcat,
> we'll fix whatever the problem was and then do another release. Version
> numbers are cheap so we just use the next one.
>
> Once any artefacts have been made public using that tag - including for
> a release vote we never delete the tag as it is part of the record of
> what was voted on.
>
> If we spot an issue with a tag before anything is uploaded, we will
> delete the tag, fix the issue and re-tag.
>
>> Perhaps the tagging/voting process should include a rc tag instead of a
>> release tag, so as to avoid getting released downstream accidentally?
>
> I don't see that happening.
>
> We have to vote on exactly what is being released. So even if we vote on
> an a.b.c-RC1 its version number has to be a.b.c. That creates an issue
> if we have multiple RCs. When a user reports an issue with version a.b.c
> we can't tell if that is a.b.c-RC1, a.b.c-RC2, a.b.c-RC3 etc.
>
> There are ways to address this with the version number (e.g. add a build
> number) but we have been doing it this way for quite a while and it
> works for us.
>
> 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.
WDYT?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Delay between release tags and announcement
Posted by Mark Thomas <ma...@apache.org>.
On 21/07/2022 07:06, Nemo wrote:
<snip/>
> What happens if a vote doesn't pass or get vetoed - do the tags get
> deleted?
Release votes cannot be vetoed.
If a release vote doesn't pass, that release doesn't happen. In Tomcat,
we'll fix whatever the problem was and then do another release. Version
numbers are cheap so we just use the next one.
Once any artefacts have been made public using that tag - including for
a release vote we never delete the tag as it is part of the record of
what was voted on.
If we spot an issue with a tag before anything is uploaded, we will
delete the tag, fix the issue and re-tag.
> Perhaps the tagging/voting process should include a rc tag instead of a
> release tag, so as to avoid getting released downstream accidentally?
I don't see that happening.
We have to vote on exactly what is being released. So even if we vote on
an a.b.c-RC1 its version number has to be a.b.c. That creates an issue
if we have multiple RCs. When a user reports an issue with version a.b.c
we can't tell if that is a.b.c-RC1, a.b.c-RC2, a.b.c-RC3 etc.
There are ways to address this with the version number (e.g. add a build
number) but we have been doing it this way for quite a while and it
works for us.
Generally, I'd strongly discourage anyone from assuming that GitHub tag
== ASF release.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org