Thread: 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]. It recently picked up the REL_15_0 tag[2], 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], 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]. 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] https://postgr.es/m/2a88ff2e-ffcc-bb39-379c-37244b4114a5%40postgresql.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