> However this does not solve the issue of stale download pages: how do you know when a release version is no longer supported?
What do you mean? Is there a requirement for that that I missed? I believe the requirement is only about removing artifacts from "downloads.a.o" and this is a completely different issue. On Mon, Nov 8, 2021 at 6:42 PM sebb <seb...@gmail.com> wrote: > > On Mon, 8 Nov 2021 at 17:11, Jarek Potiuk <ja...@potiuk.com> wrote: > > > > Yeah. We will have different URLs especially as more artifacts are > > produced (airflow has 3 of those each with different download pages). > > > > But this should be straightforward when you can add the url when > > registering the release (as Sebb proposed). According to the release > > process you should register each such "release type" separately and > > adding a URL there will do the job nicely. And initially it can be > > optional and once we figure out how to communicate it best and maybe > > try with some projects first we can make it obligatory at release > > registration. We could make it convenient - for example an easy way to > > copy a previously added URL from selected previous release or > > autocomplete from previous entries - making the process of entry as > > smooth (or even smoother) than it is today. > > Or you could just ask for the URL if the release is not already on a > download page. > This would mean parsing the page of course, but could be used to > provide immediate feedback if the page is non-conforming. > > Asking for the page might also nudge projects to move to generic pages > rather than one per release. > > However this does not solve the issue of stale download pages: how do > you know when a release version is no longer supported? > > > J. > > > > > > On Mon, Nov 8, 2021 at 4:19 PM sebb <seb...@gmail.com> wrote: > > > > > > On Mon, 8 Nov 2021 at 11:29, Hans Van Akelyen > > > <hans.van.akel...@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > I think a certain level of uniformity would not be bad for this. > > > > Having a fixed path to the downloads for each project makes it simpler > > > > for > > > > the users to "shop" for Apache projects. > > > > > > > > Having <project>.a.o/download/ as a link that should point to the > > > > resources > > > > makes it simpler for everyone. > > > > > > I agree, but expect a lot of complaints if you try to get this enforced. > > > (and there's not much point unless it is enforced). > > > > > > > Kind Regards, > > > > Hans > > > > > > > > On Mon, 8 Nov 2021 at 12:19, Justin Mclean <jus...@classsoftware.com> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > However that assumes that you know where to find the download > > > > > > page(s). > > > > > > It also assumes that projects update their download page(s) to only > > > > > > show current releases. > > > > > > > > > > It does indeed assume that, and a few other things. Currently policy > > > > > doesn't specify what the download page URL should be, but once known I > > > > > would guess it wouldn’t change often. > > > > > > > > > > Kind Regards, > > > > > Justin > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
