Обсуждение: 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