Git tag for v15
Hi,
Writing this on behalf of endoflife.date, where we track postgres
releases for the endoflife.date/postgres page.
We have our automation linked to git tags published on the postgres repo
mirror on GitHub[0]https://github.com/postgres/postgres.
It recently picked up the REL_15_0 tag[2]https://github.com/postgres/postgres/releases/tag/REL_15_0, and compiled it here:
https://github.com/endoflife-date/release-data/blob/main/releases/postgresql.json#L452
Since v15 doesn't seem to be announced yet - this is confusing me. It
doesn't impact us anywhere (yet), since we haven't added the v15 release
cycle to our page yet, but I'd like to check if this is an incorrect tag
or? If not, what's the correct source for us to use for automation purposes?
I went through the release process on the Wiki[1]https://wiki.postgresql.org/wiki/Release_process#Final_version_tagging, and it mentions final
version tagging as the final irreversible step, so that added to my
confusion.
Thanks,
Nemo
(Please keep me in cc for any replies)
[0]: https://github.com/postgres/postgres
[1]: https://wiki.postgresql.org/wiki/Release_process#Final_version_tagging
[2]: https://github.com/postgres/postgres/releases/tag/REL_15_0
On Wed, 12 Oct 2022 at 20:08, Nemo <me@captnemo.in> wrote:
Since v15 doesn't seem to be announced yet - this is confusing me. It
doesn't impact us anywhere (yet), since we haven't added the v15 release
cycle to our page yet, but I'd like to check if this is an incorrect tag
or? If not, what's the correct source for us to use for automation purposes?
Tags are usually published a few days in advance of the official
release, so that all packagers have the time to bundle and prepare the
release in their repositories. The official release is planned for
tomorrow the 13th, as mentioned in [0]/messages/by-id/2a88ff2e-ffcc-bb39-379c-37244b4114a5@postgresql.org.
This same pattern can be seen for minor release versions; where the
release is generally stamped well in advance of the release post going
live.
Kind regards,
Matthias van de Meent
[0]: /messages/by-id/2a88ff2e-ffcc-bb39-379c-37244b4114a5@postgresql.org
On 2022-Oct-12, Matthias van de Meent wrote:
On Wed, 12 Oct 2022 at 20:08, Nemo <me@captnemo.in> wrote:
Since v15 doesn't seem to be announced yet - this is confusing me. It
doesn't impact us anywhere (yet), since we haven't added the v15 release
cycle to our page yet, but I'd like to check if this is an incorrect tag
or? If not, what's the correct source for us to use for automation purposes?Tags are usually published a few days in advance of the official
release, so that all packagers have the time to bundle and prepare the
release in their repositories. The official release is planned for
tomorrow the 13th, as mentioned in [0].
To be more precise, our cadence goes pretty much every time like this
(both yearly major releases as well as quarterly minor):
- a Git commit is determined for a release on Monday (before noon
EDT/EST); a tarball produced from that commit is posted to registered
packagers
- By Tuesday evening EDT/EST, if no packagers have reported problems,
the tag corresponding to the given commit is pushed to the repo
- By Thursday noon EDT/EST the announcement is made and the packages are
made available.
Thus packagers have all of Monday and Tuesday to report problems. They
typically don't, since the buildfarm alerts us soon enough to any
portability problems. Packaging issues are normally found (and dealt
with) during beta.
If for whatever reason a problem is found before the tag has been
posted, then a new Git commit is chosen and a new tarball published.
The tag will then match the new commit, not the original obviously.
I don't know what would happen if a problem were to be found *after* the
tag has been pushed; normally that would just mean the fix would have to
wait until the next minor version in that branch. It would have to be
something really serious in order for this process to be affected.
As far as I know, this has never happened.
As far as Postgres is concerned, you could automate things so that a tag
detected on a Tuesday is marked as released on the immediately following
Thursday (noon EDT/EST). If you did this, you'd get it right 99% of the
time, and the only way to achieve 100% would be to have a bot that
follows the quarterly announcements in pgsql-announce.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
If for whatever reason a problem is found before the tag has been
posted, then a new Git commit is chosen and a new tarball published.
The tag will then match the new commit, not the original obviously.
I don't know what would happen if a problem were to be found *after* the
tag has been pushed; normally that would just mean the fix would have to
wait until the next minor version in that branch. It would have to be
something really serious in order for this process to be affected.
As far as I know, this has never happened.
I don't think it's happened since we adopted Git, anyway. The plan
if we did have to re-wrap at that point would be to increment the version
number(s), since not doing so would probably create too much confusion
about which tarballs were the correct ones.
regards, tom lane