community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Error on Release Download Page page ?
Date Fri, 16 Dec 2016 02:25:28 GMT
I haven't heard push back from what's proposed, so the following will be
reworded.

Only release artifacts that have been approved by the relevant PMC may be
linked from the download page.

All links to the mirrored distribution artifacts must not reference the
main Apache web site. They should use the standard mechanisms to distribute
the load between the mirrors.

All links to checksums, detached signatures and public keys must reference
the main Apache web site and should use https:// (SSL).

Old releases should be archived and may be linked from the download page.

All official pre-releases (e.g. milestones, alphas, betas) must removed in
a timely fashion once the final or GA version has been released.

I'll figure out if this is something I can commit to myself.

John

On Thu, Dec 8, 2016 at 6:34 AM sebb <sebbaz@gmail.com> wrote:

> On 8 December 2016 at 02:01, John D. Ament <johndament@apache.org> wrote:
> > On Wed, Dec 7, 2016 at 8:52 PM sebb <sebbaz@gmail.com> wrote:
> >
> >> On 8 December 2016 at 01:38, John D. Ament <johndament@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 <niclas@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 <
> stain@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 <johndament@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-unsubscribe@community.apache.org
> >> >> > For additional commands, e-mail: dev-help@community.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Niclas Hedhman, Software Developer
> >> >> http://zest.apache.org - New Energy for Java
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> >> For additional commands, e-mail: dev-help@community.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
> For additional commands, e-mail: dev-help@community.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message