You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@daffodil.apache.org by Steve Lawrence <sl...@apache.org> on 2022/12/15 16:00:37 UTC
Direct download links to releases?
For linking to the latest release artifacts on our webpage, we currently
use the closer.lua script described here:
https://infra.apache.org/release-download-pages.html
For example, to download the latest source release, our website links here:
https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
This goes to an HTML page listing mirrors and verification instructions.
Unfortunately, this means that if a user just uses wget/curl to download
the link, they will just get an HTML page instead of the actual zip,
which can lead to confusion when installation/checksum/gpg verification
fails. I know I've done this in the past, and just supported a user that
ran into this as well.
And I think linking to this HTML page doesn't really provide much
benefit anymore. It used to list a number of alternative mirrors, but
relatively recently it switched to only listing dlcdn.apache.org, so the
CDN automatically determines the best mirror. Additionally, our download
page already mentions that downloads should be verified, and links to
instructions on how to do so. So this page doesn't really provide any
new information.
According to first link, we still must use the closer.lua script, but we
can add the "action=download" query parameter to automatically redirect
to download the file. So for example, the above link would become:
https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
An added benefit to this is closer.lua supports archives, so we would no
longer need to change the links of previous releases to directly point
to the archive URL. For example, this link to an archived release works
fine:
https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
One downside I see to this is if you wget this URL, the resulting
filename includes the query parameter. It's a bit unhelpful since a user
would likely need to remove it, but at least they get what they
intended. There might also be a wget option to fix this, or if we do go
this route, maybe we can suggest to infra a new closer.lua script that
has the same behavior but with action=download as the default (e.d.
download.lua).
Thoughts?
Re: Direct download links to releases?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Steve,
Well, I guess that Infra usually tries to keep everything to not require any changes.
If they do, this will influence all TLPs and Podlings.
So, you can expect if something really changes here, they will prominently announce that.
Chris
From: Steve Lawrence <sl...@apache.org>
Date: Friday, 16. December 2022 at 13:22
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
No problem :)
Yeah, the idea is to still use closer.lua, but have it automatically
redirect to whatever it thinks is the best link instead of requiring a
user to click on the CDN link it normally shows. If things move away
from the CDN to something else or the mirror lists comes back, then we
can definitely reassess.
If things do change, do you know where that might be announced? I don't
remember seeing an announcement of the CDN switch, maybe I'm not
subscribed to that list?
On 12/16/22 5:09 AM, Christofer Dutz wrote:
> Sorry for all the noise,
>
> It was my impression you wanted to skip the closer.lua thing and use direct download links.
> Please ignore my mumbling ;-)
>
> Reminder to myself:
>
> * Read the email completely first
>
> * Don’t write responses before at least two units of coffee have taken effect
>
> Chris
>
>
> From: Christofer Dutz <ch...@c-ware.de>
> Date: Friday, 16. December 2022 at 10:54
> To: dev@daffodil.apache.org <de...@daffodil.apache.org>
> Subject: Re: Direct download links to releases?
> And some more info:
>
> Right now it seems people in china sometimes are having issues downloading from CDN… some projects also get redirected to a EU mirror network.
> But for folks in china, Apache seems to be working on a network of mirrors to make downloads available in china too.
>
> Chris
>
>
> From: Christofer Dutz <ch...@c-ware.de>
> Date: Friday, 16. December 2022 at 10:18
> To: dev@daffodil.apache.org <de...@daffodil.apache.org>
> Subject: Re: Direct download links to releases?
> Hi all,
>
> Ups ... sorry for coming late …. But I think we can’t change this.
> Thew latest versions of all our Apache software it the parts that gets the most downloads.
>
> In the past we had many mirrors which this script redistributed to.
>
> Right now, Apache has a sponsored hosting, which is dlcdn.apache.org … however we don’t know how long this sponsorship will be available, so with the script we’re able to switch mirrors quite fast.
>
> So, if you change the scripts to use that … be prepared for it breaking in the future.
>
> Chris
>
>
>
>
> From: Steve Lawrence <sl...@apache.org>
> Date: Thursday, 15. December 2022 at 19:16
> To: dev@daffodil.apache.org <de...@daffodil.apache.org>
> Subject: Re: Direct download links to releases?
> Since there are no immediate objections, I've created a PR to add this.
>
> I've also discovered that downloads.apache.org and closer.lua and aware
> of archives and so we can actually use the same links for all releases,
> including those that are archived. That removes one manual step of
> changing links of previous releases in the release process.
>
> https://github.com/apache/daffodil-site/pull/102
>
> On 12/15/22 11:51 AM, Interrante, John A (GE Research, US) wrote:
>> +1
>>
>> Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
>>
>> John
>>
>> -----Original Message-----
>> From: Steve Lawrence <sl...@apache.org>
>> Sent: Thursday, December 15, 2022 11:01 AM
>> To: dev@daffodil.apache.org
>> Subject: EXT: Direct download links to releases?
>>
>> For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
>>
>> https://infra.apache.org/release-download-pages.html
>>
>> For example, to download the latest source release, our website links here:
>>
>>
>> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>>
>> This goes to an HTML page listing mirrors and verification instructions.
>>
>> Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
>>
>> And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
>>
>> According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
>>
>>
>> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>>
>> An added benefit to this is closer.lua supports archives, so we would no
>> longer need to change the links of previous releases to directly point
>> to the archive URL. For example, this link to an archived release works
>> fine:
>>
>>
>> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>>
>> One downside I see to this is if you wget this URL, the resulting
>> filename includes the query parameter. It's a bit unhelpful since a user
>> would likely need to remove it, but at least they get what they
>> intended. There might also be a wget option to fix this, or if we do go
>> this route, maybe we can suggest to infra a new closer.lua script that
>> has the same behavior but with action=download as the default (e.d.
>> download.lua).
>>
>> Thoughts?
>
Re: Direct download links to releases?
Posted by Steve Lawrence <sl...@apache.org>.
No problem :)
Yeah, the idea is to still use closer.lua, but have it automatically
redirect to whatever it thinks is the best link instead of requiring a
user to click on the CDN link it normally shows. If things move away
from the CDN to something else or the mirror lists comes back, then we
can definitely reassess.
If things do change, do you know where that might be announced? I don't
remember seeing an announcement of the CDN switch, maybe I'm not
subscribed to that list?
On 12/16/22 5:09 AM, Christofer Dutz wrote:
> Sorry for all the noise,
>
> It was my impression you wanted to skip the closer.lua thing and use direct download links.
> Please ignore my mumbling ;-)
>
> Reminder to myself:
>
> * Read the email completely first
>
> * Don’t write responses before at least two units of coffee have taken effect
>
> Chris
>
>
> From: Christofer Dutz <ch...@c-ware.de>
> Date: Friday, 16. December 2022 at 10:54
> To: dev@daffodil.apache.org <de...@daffodil.apache.org>
> Subject: Re: Direct download links to releases?
> And some more info:
>
> Right now it seems people in china sometimes are having issues downloading from CDN… some projects also get redirected to a EU mirror network.
> But for folks in china, Apache seems to be working on a network of mirrors to make downloads available in china too.
>
> Chris
>
>
> From: Christofer Dutz <ch...@c-ware.de>
> Date: Friday, 16. December 2022 at 10:18
> To: dev@daffodil.apache.org <de...@daffodil.apache.org>
> Subject: Re: Direct download links to releases?
> Hi all,
>
> Ups ... sorry for coming late …. But I think we can’t change this.
> Thew latest versions of all our Apache software it the parts that gets the most downloads.
>
> In the past we had many mirrors which this script redistributed to.
>
> Right now, Apache has a sponsored hosting, which is dlcdn.apache.org … however we don’t know how long this sponsorship will be available, so with the script we’re able to switch mirrors quite fast.
>
> So, if you change the scripts to use that … be prepared for it breaking in the future.
>
> Chris
>
>
>
>
> From: Steve Lawrence <sl...@apache.org>
> Date: Thursday, 15. December 2022 at 19:16
> To: dev@daffodil.apache.org <de...@daffodil.apache.org>
> Subject: Re: Direct download links to releases?
> Since there are no immediate objections, I've created a PR to add this.
>
> I've also discovered that downloads.apache.org and closer.lua and aware
> of archives and so we can actually use the same links for all releases,
> including those that are archived. That removes one manual step of
> changing links of previous releases in the release process.
>
> https://github.com/apache/daffodil-site/pull/102
>
> On 12/15/22 11:51 AM, Interrante, John A (GE Research, US) wrote:
>> +1
>>
>> Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
>>
>> John
>>
>> -----Original Message-----
>> From: Steve Lawrence <sl...@apache.org>
>> Sent: Thursday, December 15, 2022 11:01 AM
>> To: dev@daffodil.apache.org
>> Subject: EXT: Direct download links to releases?
>>
>> For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
>>
>> https://infra.apache.org/release-download-pages.html
>>
>> For example, to download the latest source release, our website links here:
>>
>>
>> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>>
>> This goes to an HTML page listing mirrors and verification instructions.
>>
>> Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
>>
>> And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
>>
>> According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
>>
>>
>> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>>
>> An added benefit to this is closer.lua supports archives, so we would no
>> longer need to change the links of previous releases to directly point
>> to the archive URL. For example, this link to an archived release works
>> fine:
>>
>>
>> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>>
>> One downside I see to this is if you wget this URL, the resulting
>> filename includes the query parameter. It's a bit unhelpful since a user
>> would likely need to remove it, but at least they get what they
>> intended. There might also be a wget option to fix this, or if we do go
>> this route, maybe we can suggest to infra a new closer.lua script that
>> has the same behavior but with action=download as the default (e.d.
>> download.lua).
>>
>> Thoughts?
>
Re: Direct download links to releases?
Posted by Christofer Dutz <ch...@c-ware.de>.
Sorry for all the noise,
It was my impression you wanted to skip the closer.lua thing and use direct download links.
Please ignore my mumbling ;-)
Reminder to myself:
* Read the email completely first
* Don’t write responses before at least two units of coffee have taken effect
Chris
From: Christofer Dutz <ch...@c-ware.de>
Date: Friday, 16. December 2022 at 10:54
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
And some more info:
Right now it seems people in china sometimes are having issues downloading from CDN… some projects also get redirected to a EU mirror network.
But for folks in china, Apache seems to be working on a network of mirrors to make downloads available in china too.
Chris
From: Christofer Dutz <ch...@c-ware.de>
Date: Friday, 16. December 2022 at 10:18
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
Hi all,
Ups ... sorry for coming late …. But I think we can’t change this.
Thew latest versions of all our Apache software it the parts that gets the most downloads.
In the past we had many mirrors which this script redistributed to.
Right now, Apache has a sponsored hosting, which is dlcdn.apache.org … however we don’t know how long this sponsorship will be available, so with the script we’re able to switch mirrors quite fast.
So, if you change the scripts to use that … be prepared for it breaking in the future.
Chris
From: Steve Lawrence <sl...@apache.org>
Date: Thursday, 15. December 2022 at 19:16
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
Since there are no immediate objections, I've created a PR to add this.
I've also discovered that downloads.apache.org and closer.lua and aware
of archives and so we can actually use the same links for all releases,
including those that are archived. That removes one manual step of
changing links of previous releases in the release process.
https://github.com/apache/daffodil-site/pull/102
On 12/15/22 11:51 AM, Interrante, John A (GE Research, US) wrote:
> +1
>
> Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <sl...@apache.org>
> Sent: Thursday, December 15, 2022 11:01 AM
> To: dev@daffodil.apache.org
> Subject: EXT: Direct download links to releases?
>
> For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
>
> https://infra.apache.org/release-download-pages.html
>
> For example, to download the latest source release, our website links here:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>
> This goes to an HTML page listing mirrors and verification instructions.
>
> Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
>
> And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
>
> According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>
> An added benefit to this is closer.lua supports archives, so we would no
> longer need to change the links of previous releases to directly point
> to the archive URL. For example, this link to an archived release works
> fine:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>
> One downside I see to this is if you wget this URL, the resulting
> filename includes the query parameter. It's a bit unhelpful since a user
> would likely need to remove it, but at least they get what they
> intended. There might also be a wget option to fix this, or if we do go
> this route, maybe we can suggest to infra a new closer.lua script that
> has the same behavior but with action=download as the default (e.d.
> download.lua).
>
> Thoughts?
Re: Direct download links to releases?
Posted by Christofer Dutz <ch...@c-ware.de>.
And some more info:
Right now it seems people in china sometimes are having issues downloading from CDN… some projects also get redirected to a EU mirror network.
But for folks in china, Apache seems to be working on a network of mirrors to make downloads available in china too.
Chris
From: Christofer Dutz <ch...@c-ware.de>
Date: Friday, 16. December 2022 at 10:18
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
Hi all,
Ups ... sorry for coming late …. But I think we can’t change this.
Thew latest versions of all our Apache software it the parts that gets the most downloads.
In the past we had many mirrors which this script redistributed to.
Right now, Apache has a sponsored hosting, which is dlcdn.apache.org … however we don’t know how long this sponsorship will be available, so with the script we’re able to switch mirrors quite fast.
So, if you change the scripts to use that … be prepared for it breaking in the future.
Chris
From: Steve Lawrence <sl...@apache.org>
Date: Thursday, 15. December 2022 at 19:16
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
Since there are no immediate objections, I've created a PR to add this.
I've also discovered that downloads.apache.org and closer.lua and aware
of archives and so we can actually use the same links for all releases,
including those that are archived. That removes one manual step of
changing links of previous releases in the release process.
https://github.com/apache/daffodil-site/pull/102
On 12/15/22 11:51 AM, Interrante, John A (GE Research, US) wrote:
> +1
>
> Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <sl...@apache.org>
> Sent: Thursday, December 15, 2022 11:01 AM
> To: dev@daffodil.apache.org
> Subject: EXT: Direct download links to releases?
>
> For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
>
> https://infra.apache.org/release-download-pages.html
>
> For example, to download the latest source release, our website links here:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>
> This goes to an HTML page listing mirrors and verification instructions.
>
> Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
>
> And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
>
> According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>
> An added benefit to this is closer.lua supports archives, so we would no
> longer need to change the links of previous releases to directly point
> to the archive URL. For example, this link to an archived release works
> fine:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>
> One downside I see to this is if you wget this URL, the resulting
> filename includes the query parameter. It's a bit unhelpful since a user
> would likely need to remove it, but at least they get what they
> intended. There might also be a wget option to fix this, or if we do go
> this route, maybe we can suggest to infra a new closer.lua script that
> has the same behavior but with action=download as the default (e.d.
> download.lua).
>
> Thoughts?
Re: Direct download links to releases?
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi all,
Ups ... sorry for coming late …. But I think we can’t change this.
Thew latest versions of all our Apache software it the parts that gets the most downloads.
In the past we had many mirrors which this script redistributed to.
Right now, Apache has a sponsored hosting, which is dlcdn.apache.org … however we don’t know how long this sponsorship will be available, so with the script we’re able to switch mirrors quite fast.
So, if you change the scripts to use that … be prepared for it breaking in the future.
Chris
From: Steve Lawrence <sl...@apache.org>
Date: Thursday, 15. December 2022 at 19:16
To: dev@daffodil.apache.org <de...@daffodil.apache.org>
Subject: Re: Direct download links to releases?
Since there are no immediate objections, I've created a PR to add this.
I've also discovered that downloads.apache.org and closer.lua and aware
of archives and so we can actually use the same links for all releases,
including those that are archived. That removes one manual step of
changing links of previous releases in the release process.
https://github.com/apache/daffodil-site/pull/102
On 12/15/22 11:51 AM, Interrante, John A (GE Research, US) wrote:
> +1
>
> Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <sl...@apache.org>
> Sent: Thursday, December 15, 2022 11:01 AM
> To: dev@daffodil.apache.org
> Subject: EXT: Direct download links to releases?
>
> For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
>
> https://infra.apache.org/release-download-pages.html
>
> For example, to download the latest source release, our website links here:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>
> This goes to an HTML page listing mirrors and verification instructions.
>
> Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
>
> And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
>
> According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>
> An added benefit to this is closer.lua supports archives, so we would no
> longer need to change the links of previous releases to directly point
> to the archive URL. For example, this link to an archived release works
> fine:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>
> One downside I see to this is if you wget this URL, the resulting
> filename includes the query parameter. It's a bit unhelpful since a user
> would likely need to remove it, but at least they get what they
> intended. There might also be a wget option to fix this, or if we do go
> this route, maybe we can suggest to infra a new closer.lua script that
> has the same behavior but with action=download as the default (e.d.
> download.lua).
>
> Thoughts?
Re: Direct download links to releases?
Posted by Steve Lawrence <sl...@apache.org>.
Since there are no immediate objections, I've created a PR to add this.
I've also discovered that downloads.apache.org and closer.lua and aware
of archives and so we can actually use the same links for all releases,
including those that are archived. That removes one manual step of
changing links of previous releases in the release process.
https://github.com/apache/daffodil-site/pull/102
On 12/15/22 11:51 AM, Interrante, John A (GE Research, US) wrote:
> +1
>
> Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <sl...@apache.org>
> Sent: Thursday, December 15, 2022 11:01 AM
> To: dev@daffodil.apache.org
> Subject: EXT: Direct download links to releases?
>
> For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
>
> https://infra.apache.org/release-download-pages.html
>
> For example, to download the latest source release, our website links here:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>
> This goes to an HTML page listing mirrors and verification instructions.
>
> Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
>
> And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
>
> According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>
> An added benefit to this is closer.lua supports archives, so we would no
> longer need to change the links of previous releases to directly point
> to the archive URL. For example, this link to an archived release works
> fine:
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>
> One downside I see to this is if you wget this URL, the resulting
> filename includes the query parameter. It's a bit unhelpful since a user
> would likely need to remove it, but at least they get what they
> intended. There might also be a wget option to fix this, or if we do go
> this route, maybe we can suggest to infra a new closer.lua script that
> has the same behavior but with action=download as the default (e.d.
> download.lua).
>
> Thoughts?
RE: Direct download links to releases?
Posted by "Interrante, John A (GE Research, US)" <Jo...@ge.com>.
+1
Using direct download links sounds better to me too. Both curl and wget have curl -o, --output file and wget -O, --output-document=file options to avoid needing to rename the file after downloading it. We can mention these options somewhere in the same places where we already mention that downloads should be verified and how to do so.
John
-----Original Message-----
From: Steve Lawrence <sl...@apache.org>
Sent: Thursday, December 15, 2022 11:01 AM
To: dev@daffodil.apache.org
Subject: EXT: Direct download links to releases?
For linking to the latest release artifacts on our webpage, we currently use the closer.lua script described here:
https://infra.apache.org/release-download-pages.html
For example, to download the latest source release, our website links here:
https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
This goes to an HTML page listing mirrors and verification instructions.
Unfortunately, this means that if a user just uses wget/curl to download the link, they will just get an HTML page instead of the actual zip, which can lead to confusion when installation/checksum/gpg verification fails. I know I've done this in the past, and just supported a user that ran into this as well.
And I think linking to this HTML page doesn't really provide much benefit anymore. It used to list a number of alternative mirrors, but relatively recently it switched to only listing dlcdn.apache.org, so the CDN automatically determines the best mirror. Additionally, our download page already mentions that downloads should be verified, and links to instructions on how to do so. So this page doesn't really provide any new information.
According to first link, we still must use the closer.lua script, but we can add the "action=download" query parameter to automatically redirect to download the file. So for example, the above link would become:
https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
An added benefit to this is closer.lua supports archives, so we would no
longer need to change the links of previous releases to directly point
to the archive URL. For example, this link to an archived release works
fine:
https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
One downside I see to this is if you wget this URL, the resulting
filename includes the query parameter. It's a bit unhelpful since a user
would likely need to remove it, but at least they get what they
intended. There might also be a wget option to fix this, or if we do go
this route, maybe we can suggest to infra a new closer.lua script that
has the same behavior but with action=download as the default (e.d.
download.lua).
Thoughts?
Re: Direct download links to releases?
Posted by Davin Shearer <sc...@gmail.com>.
Hi Steve,
As a developer, I like to script things that I need to do repeatedly, to
the extent possible, and regularly use wget and curl. I'm on board with
whatever can be done to make it simple for developers to script fetching
these artifacts with minimal frustration.
+1 for me.
-Davin
On Thu, Dec 15, 2022 at 11:00 AM Steve Lawrence <sl...@apache.org>
wrote:
> For linking to the latest release artifacts on our webpage, we currently
> use the closer.lua script described here:
>
> https://infra.apache.org/release-download-pages.html
>
> For example, to download the latest source release, our website links here:
>
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip
>
> This goes to an HTML page listing mirrors and verification instructions.
>
> Unfortunately, this means that if a user just uses wget/curl to download
> the link, they will just get an HTML page instead of the actual zip,
> which can lead to confusion when installation/checksum/gpg verification
> fails. I know I've done this in the past, and just supported a user that
> ran into this as well.
>
> And I think linking to this HTML page doesn't really provide much
> benefit anymore. It used to list a number of alternative mirrors, but
> relatively recently it switched to only listing dlcdn.apache.org, so the
> CDN automatically determines the best mirror. Additionally, our download
> page already mentions that downloads should be verified, and links to
> instructions on how to do so. So this page doesn't really provide any
> new information.
>
> According to first link, we still must use the closer.lua script, but we
> can add the "action=download" query parameter to automatically redirect
> to download the file. So for example, the above link would become:
>
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.4.0/src/apache-daffodil-3.4.0-src.zip?action=download
>
> An added benefit to this is closer.lua supports archives, so we would no
> longer need to change the links of previous releases to directly point
> to the archive URL. For example, this link to an archived release works
> fine:
>
>
>
> https://www.apache.org/dyn/closer.lua/daffodil/3.3.0/src/apache-daffodil-3.3.0-src.zip?action=download
>
> One downside I see to this is if you wget this URL, the resulting
> filename includes the query parameter. It's a bit unhelpful since a user
> would likely need to remove it, but at least they get what they
> intended. There might also be a wget option to fix this, or if we do go
> this route, maybe we can suggest to infra a new closer.lua script that
> has the same behavior but with action=download as the default (e.d.
> download.lua).
>
> Thoughts?
>