Compiling the release experience.
Apache httpd 2.4.49 was released on September 15/16 20201.
There were changes to the release process and some resulting
hickups, but it went through.
New in the release process were:
- a switch from always incrementing version numbers to
release candidate numberings.
- adaptations of our process to the general apache security
CVE handling from cveprocess.apache.org
The switch away from incrementing version numbers before
a release voting led in the past to confusions to our users
and extra work on our part. Users, for example, overlooked
CHANGES reported on unreleased versions. CVEs were reported
on versions the users never saw.
With the new release candidate numbers, we can keep the next
release number stable (whatever source revision will be selected).
We can now communicate "this will be fixed in 2.4.50" and this
will be the version that users get.
The CVE handling via cveprocess.apache.org is seen as an
overall improvements to the process. However, lacking an
API usable for automation, it still involves manual steps
which we would like to automate more.
For example, since we cannot download CVE JSON data, release
and "readiness" scripts could not do a full status check. This
led to missing fields being unnoticed during release. As
a result, vulnerability pages became 404s on our site and
we needed manual intervention to get it right.
We will adjust our processes to have a minimum of manual
steps here and check data completeness before release. We hope
that mid-term, the cveprocess site can offer non-browser access
to features. Maybe apache infra can be of help. This should
be beneficial to all apache projects.
Then we had some things fumbled by our new release manager (myself):
- the RMs PGP key was kept in the KEYS file, but not registered
in the directories and as its apache committers pgp key. This
led to irritations for folks that verified our tarballs.
- The general announcement emails did not go through for
announce@apache.org, moderators did not see it. The issue,
as it turned out later, was that the RM was not subscribed to
that list with his apache email id. The list silently dropped
the mails.
- A twitter announcement for @apache_httpd was not generated.
We need to handshake with the holder of that handle on how to
get this out in the future.
This should serve as a record for things to improve in the next
release - while memory of this one is still fresh. Please add to
this anything I might have missed or additional things you like
us to tackle in the next release.
Thanks,
Stefan
Apache httpd 2.4.49 was released on September 15/16 20201.
There were changes to the release process and some resulting
hickups, but it went through.
New in the release process were:
- a switch from always incrementing version numbers to
release candidate numberings.
- adaptations of our process to the general apache security
CVE handling from cveprocess.apache.org
The switch away from incrementing version numbers before
a release voting led in the past to confusions to our users
and extra work on our part. Users, for example, overlooked
CHANGES reported on unreleased versions. CVEs were reported
on versions the users never saw.
With the new release candidate numbers, we can keep the next
release number stable (whatever source revision will be selected).
We can now communicate "this will be fixed in 2.4.50" and this
will be the version that users get.
The CVE handling via cveprocess.apache.org is seen as an
overall improvements to the process. However, lacking an
API usable for automation, it still involves manual steps
which we would like to automate more.
For example, since we cannot download CVE JSON data, release
and "readiness" scripts could not do a full status check. This
led to missing fields being unnoticed during release. As
a result, vulnerability pages became 404s on our site and
we needed manual intervention to get it right.
We will adjust our processes to have a minimum of manual
steps here and check data completeness before release. We hope
that mid-term, the cveprocess site can offer non-browser access
to features. Maybe apache infra can be of help. This should
be beneficial to all apache projects.
Then we had some things fumbled by our new release manager (myself):
- the RMs PGP key was kept in the KEYS file, but not registered
in the directories and as its apache committers pgp key. This
led to irritations for folks that verified our tarballs.
- The general announcement emails did not go through for
announce@apache.org, moderators did not see it. The issue,
as it turned out later, was that the RM was not subscribed to
that list with his apache email id. The list silently dropped
the mails.
- A twitter announcement for @apache_httpd was not generated.
We need to handshake with the holder of that handle on how to
get this out in the future.
This should serve as a record for things to improve in the next
release - while memory of this one is still fresh. Please add to
this anything I might have missed or additional things you like
us to tackle in the next release.
Thanks,
Stefan