On 8 December 2016 at 02:01, John D. Ament <johndam...@apache.org> wrote: > On Wed, Dec 7, 2016 at 8:52 PM sebb <seb...@gmail.com> wrote: > >> On 8 December 2016 at 01:38, John D. Ament <johndam...@apache.org> wrote: >> > For me, the key is the "official release" - an official release has been >> > voted on by the relevant PMC and approved for use. The labeling of it - >> > alpha, beta, etc is moot. Maybe we should take out that part and instead >> > use: >> > >> > Only release artifacts that have been approved by the relevant PMC may be >> > linked from the download page. All other download links should be removed >> > in a timely fashion. >> >> "All other download links should be removed" - there is no grace period. >> >> The reference to timely removal of links applies to alpha/beta/etc >> releases which are expected to be short-lived. >> They should not remain on the page once the full GA release has been >> published. >> >> However I think it would be better to mostly keep the original >> wording, but tweaked to remove the ambiguity. >> > > So how about... > > > (bullet 4) - Only release artifacts that have been approved by > the relevant PMC may be linked from the download page.
I would put that as the first bullet point as it is the most important to get across. > (bullet 5 - new) - All official pre-releases (e.g. milestones, alphas, > betas) must removed in a timely fashion once the final or GA version has > been released. +1 > It seems to me that the current bullet 4 is blending two problems, or maybe > I'm making it up in my head. I don't think it does mix issues. It only talks about non-GA releases, but does so ambiguously. > John > > >> >> > ? >> > >> > On Wed, Dec 7, 2016 at 8:32 PM Niclas Hedhman <nic...@hedhman.org> >> wrote: >> > >> >> I agree with Stian. It was discussed ~12-14 years ago, how to deal with >> >> "release for public consumption", "release for beta testers", "nightly >> >> builds" and so on. And AFAIR, the Stian's explanation mirrors the >> consensus >> >> from back then, and perhaps the wording is not optimal. >> >> >> >> Niclas >> >> >> >> On Wed, Dec 7, 2016 at 10:31 PM, Stian Soiland-Reyes <st...@apache.org> >> >> wrote: >> >> >> >> > Hang on, it's perfectly fine for ASF projects to publish and link to >> >> > milestone/alpha/beta releases - as long as they have also gone through >> >> > a formal release VOTE and checking, they are still "official >> >> > releases". >> >> > >> >> > http://www.apache.org/dev/release.html#release-types >> >> > >> >> > What is confusing about your quoted pagraph is that it uses the >> >> > terminology "not full official releases" misleadingly -- but those >> >> > should still be "official releases" - just not at a "stable" or >> >> > "general availability" maturity level. >> >> > >> >> > What is NOT ok is to link from the download page to a non-voted on >> >> > SNAPSHOT build or similar. That is quite clearly explained in >> >> > http://www.apache.org/dev/release.html - but perhaps not on >> >> > release-download-pages.html. >> >> > >> >> > On 7 December 2016 at 12:31, John D. Ament <johndam...@apache.org> >> >> wrote: >> >> > > The following text is found on >> >> > > http://www.apache.org/dev/release-download-pages.html#links (4th >> >> bullet >> >> > in >> >> > > that section) >> >> > > >> >> > > Artifacts which are not full official releases (for example, >> >> milestones, >> >> > > betas and alphas) may be linked from the download page. Links to >> these >> >> > > artifacts should be removed in a timely fashion. >> >> > > >> >> > > I believe it's missing a "not" and should be >> >> > > >> >> > > Artifacts which are not full official releases (for example, >> >> milestones, >> >> > > betas and alphas) may not be linked from the download page. Links to >> >> > these >> >> > > artifacts should be removed in a timely fashion. >> >> > >> >> > >> >> > >> >> > -- >> >> > Stian Soiland-Reyes >> >> > http://orcid.org/0000-0001-9842-9718 >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> >> > For additional commands, e-mail: dev-h...@community.apache.org >> >> > >> >> > >> >> >> >> >> >> -- >> >> Niclas Hedhman, Software Developer >> >> http://zest.apache.org - New Energy for Java >> >> >> >> --------------------------------------------------------------------- >> 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
