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. 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
