Thread: Publishing 14 source snapshots?
Hello, Today I noticed that the branch snapshots at https://ftp.postgresql.org/pub/snapshot/ have folders for 13 and 15 (dev), but there are no 14 snapshots yet. Is this the right place to request those? Thanks, --Jacob
On 9/16/21 9:08 AM, Jacob Champion wrote: > Hello, > > Today I noticed that the branch snapshots at > https://ftp.postgresql.org/pub/snapshot/ have folders for 13 and 15 > (dev), but there are no 14 snapshots yet. Is this the right place to > request those? 14 is in Beta: https://www.postgresql.org/developer/beta/ So: https://www.postgresql.org/ftp/source/v14beta3/ > > Thanks, > --Jacob > -- Adrian Klaver adrian.klaver@aklaver.com
On Thu, 2021-09-16 at 09:12 -0700, Adrian Klaver wrote: > 14 is in Beta: Yep, we've been using those artifacts for now as a workaround. In our case, it'd be nice to have daily snapshots for the 14 stable branch during beta, so that we don't have to keep updating our CIs as new betas/RCs drop. But if we just need to wait until the 14 release later this month, we can do that too. Thanks! --Jacob
On 9/16/21 9:41 AM, Jacob Champion wrote: > On Thu, 2021-09-16 at 09:12 -0700, Adrian Klaver wrote: >> 14 is in Beta: > > Yep, we've been using those artifacts for now as a workaround. In our > case, it'd be nice to have daily snapshots for the 14 stable branch I knew there was an explanation for this, see here: https://www.postgresql.org/download/snapshots/ "Beta and Release Candidate packages are built prior to the release of new major versions of PostgreSQL. They are not built continually." ... "Source code Beta and Release Candidate tarballs are made available alongside the release tarballs during the final phases of the development cycle of new major versions of PostgreSQL. Source code tarballs are built automatically every night on the official PostgreSQL development server. The development snapshot is taken from the head of the git repository, and includes the new features being worked on for the next release. There are also "branch tip" snapshots built from all supported stable branches, which contains all bugfixes that are scheduled for the next release. " > during beta, so that we don't have to keep updating our CIs as new > betas/RCs drop. But if we just need to wait until the 14 release later > this month, we can do that too. You could go here: https://github.com/postgres/postgres and grab the REL_14_STABLE branch. > > Thanks! > --Jacob > -- Adrian Klaver adrian.klaver@aklaver.com
On Thu, 2021-09-16 at 10:50 -0700, Adrian Klaver wrote: > On 9/16/21 9:41 AM, Jacob Champion wrote: > > On Thu, 2021-09-16 at 09:12 -0700, Adrian Klaver wrote: > > > 14 is in Beta: > > > > Yep, we've been using those artifacts for now as a workaround. In our > > case, it'd be nice to have daily snapshots for the 14 stable branch > > I knew there was an explanation for this, see here: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgresql.org%2Fdownload%2Fsnapshots%2F&data=04%7C01%7Cpchampion%40vmware.com%7C6b54f08db86b436a555b08d9793a7ed5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637674114423690457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=I4oJOoV796iFyeFPmPSOwT%2BSvzAptf1B1CQe3usIjEI%3D&reserved=0 > > "Beta and Release Candidate packages are built prior to the release of > new major versions of PostgreSQL. They are not built continually." Right -- I'd assumed that was because pg_upgrade has to support betas and RCs, so it's useful to have defined points in time for official support. In our case, we don't want the "official" builds; we just want to track the 14 branch, similar to the way we can track the dev (15) snapshot folder. > There are also "branch tip" snapshots > built from all supported stable branches, which contains all bugfixes > that are scheduled for the next release. " This is the sentence that seemed to cover it for me -- I thought 14 would be considered one of the stable branches for which snapshots would be useful, even during beta. > You could go here: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpostgres%2Fpostgres&data=04%7C01%7Cpchampion%40vmware.com%7C6b54f08db86b436a555b08d9793a7ed5%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637674114423690457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1sUIhEDvtRsmD8EzqtI5zd4rOmc7rBfNZUVr80GfB1o%3D&reserved=0 > > and grab the REL_14_STABLE branch. Absolutely -- this isn't a hard blocker for us; it's just a special case in our CI that I'd rather didn't exist... Maybe it'd be worthwhile to ask on -hackers for an update to the snapshot policy? Thanks, --Jacob
Jacob Champion <pchampion@vmware.com> writes: > Absolutely -- this isn't a hard blocker for us; it's just a special > case in our CI that I'd rather didn't exist... Maybe it'd be worthwhile > to ask on -hackers for an update to the snapshot policy? This would be the right list to ask for that, I think. -hackers doesn't deal in website issues. regards, tom lane
On Thu, 2021-09-16 at 15:59 -0400, Tom Lane wrote: > Jacob Champion <pchampion@vmware.com> writes: > > Absolutely -- this isn't a hard blocker for us; it's just a special > > case in our CI that I'd rather didn't exist... Maybe it'd be worthwhile > > to ask on -hackers for an update to the snapshot policy? > > This would be the right list to ask for that, I think. -hackers doesn't > deal in website issues. Cool. Consider this a feature request, then, to have dev snapshots for every STABLE branch, even during beta periods, for CIs that are watching the latest development state and want to be handed a tarball rather than git-clone. (It's not a big deal in the end, just an annoyance.) --Jacob
On Thu, Sep 16, 2021 at 10:49 PM Jacob Champion <pchampion@vmware.com> wrote: > > On Thu, 2021-09-16 at 15:59 -0400, Tom Lane wrote: > > Jacob Champion <pchampion@vmware.com> writes: > > > Absolutely -- this isn't a hard blocker for us; it's just a special > > > case in our CI that I'd rather didn't exist... Maybe it'd be worthwhile > > > to ask on -hackers for an update to the snapshot policy? > > > > This would be the right list to ask for that, I think. -hackers doesn't > > deal in website issues. > > Cool. Consider this a feature request, then, to have dev snapshots for > every STABLE branch, even during beta periods, for CIs that are > watching the latest development state and want to be handed a tarball > rather than git-clone. (It's not a big deal in the end, just an > annoyance.) This is much simpler than what's been speculated about in this thread. REL_14_STABLE was simply not added to the list of what to build for. Because, well, nobody did that. FWIW, you can also see this by looking at which branches the buildfarm animal guaibasaurus builds for because it's the same list. I've enabled it now and kicked off a run, so it should show up shortly. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
On 9/17/21 5:28 AM, Magnus Hagander wrote: > On Thu, Sep 16, 2021 at 10:49 PM Jacob Champion <pchampion@vmware.com> wrote: >> >> On Thu, 2021-09-16 at 15:59 -0400, Tom Lane wrote: >> > Jacob Champion <pchampion@vmware.com> writes: >> > > Absolutely -- this isn't a hard blocker for us; it's just a special >> > > case in our CI that I'd rather didn't exist... Maybe it'd be worthwhile >> > > to ask on -hackers for an update to the snapshot policy? >> > >> > This would be the right list to ask for that, I think. -hackers doesn't >> > deal in website issues. >> >> Cool. Consider this a feature request, then, to have dev snapshots for >> every STABLE branch, even during beta periods, for CIs that are >> watching the latest development state and want to be handed a tarball >> rather than git-clone. (It's not a big deal in the end, just an >> annoyance.) > > This is much simpler than what's been speculated about in this thread. > > REL_14_STABLE was simply not added to the list of what to build for. > Because, well, nobody did that. > > FWIW, you can also see this by looking at which branches the buildfarm > animal guaibasaurus builds for because it's the same list. > > I've enabled it now and kicked off a run, so it should show up shortly. The next logical question is, what process/procedure/script should this be added to so that it happens next time without extra prodding ;-) Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Joe Conway <mail@joeconway.com> writes: > On 9/17/21 5:28 AM, Magnus Hagander wrote: >> REL_14_STABLE was simply not added to the list of what to build for. >> Because, well, nobody did that. > The next logical question is, what process/procedure/script should this > be added to so that it happens next time without extra prodding ;-) Seems to me it'd be sensible to turn it on as soon as a new branch is forked off. Isn't there already a pginfra checklist for that? regards, tom lane
On Fri, 2021-09-17 at 11:28 +0200, Magnus Hagander wrote: > This is much simpler than what's been speculated about in this thread. > > REL_14_STABLE was simply not added to the list of what to build for. > Because, well, nobody did that. > > FWIW, you can also see this by looking at which branches the buildfarm > animal guaibasaurus builds for because it's the same list. > > I've enabled it now and kicked off a run, so it should show up shortly. Thank you Magnus! --Jacob
On Fri, Sep 17, 2021 at 3:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Joe Conway <mail@joeconway.com> writes:
> On 9/17/21 5:28 AM, Magnus Hagander wrote:
>> REL_14_STABLE was simply not added to the list of what to build for.
>> Because, well, nobody did that.
> The next logical question is, what process/procedure/script should this
> be added to so that it happens next time without extra prodding ;-)
Seems to me it'd be sensible to turn it on as soon as a new branch is
forked off. Isn't there already a pginfra checklist for that?
There hasn't been, only for making releases, but there should have been. It's now also been added to our monitoring in case it's missed for next time.