I was also talking more from a user perspective. It's not that hard to create a one pager that contains the latest version, release dates, release notes and keys for all packages the project provides.
In the case of Airflow it's pretty much what you put in announcements, and this one is fairly obvious to find. On some other projects you really have to start digging. And I am not sure I would want yet another xml/json/yaml config file that has to be maintained when creating a release. eg. you should update your DOAP file too ( https://projects.apache.org/project.html?airflow) as Dave said, many projects fail to do so. Maybe the download page url should be configurable (use the DOAP?), but I would rather have a uniform way of finding that page. On Mon, 8 Nov 2021 at 19:11, Dave Fisher <w...@apache.org> wrote: > > > > On Nov 8, 2021, at 9:48 AM, Jarek Potiuk <ja...@potiuk.com> wrote: > > > >> 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. > > There is no definitive rule about the path to the download page. There is > no standard and with over 200 projects, 35 podlings, and lots of products > change is difficult. > > There is one definite requirement that can be checked. Whether the > releases in svn are properly formed. > > We do this in the Incubator with the Clutch Analysis. > https://svn.apache.org/repos/asf/incubator/public/trunk/clutch2.py - L1132 > Output found by clicking on a podling on > https://incubator.apache.org/clutch/ > > We also have code in ASF Pelican - > https://github.com/apache/infrastructure-pelican/blob/master/plugins/asfdata.py#L362 > That was used to produce this example for Hadoop - > https://template.staged.apache.org/downloads.html > Using this template - > https://github.com/apache/template-site/blob/main/content/downloads.ezmd > Control is - > https://github.com/apache/template-site/blob/main/asfdata.yaml#L110 > > To review projects you might find out where their download page is by > reviewing the project DOAP file, but we’ve never been able to get all > projects to maintain one. > > Maybe it’s time to more carefully define what the ask is here. > > > > > 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
