commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: release vs. SNAPSHOT sites.
Date Sun, 27 Jul 2014 14:15:56 GMT
On Sun, Jul 27, 2014 at 4:24 AM, sebb <sebbaz@gmail.com> wrote:

> On 26 July 2014 19:09, Phil Steitz <phil.steitz@gmail.com> wrote:
> >
> >
> >> On Jul 26, 2014, at 6:16 AM, Gary Gregory <garydgregory@gmail.com>
> wrote:
> >>
> >> OK, so do we want:
> >>
> >> - Always have the release site be the "main" site.
> >> - Optionally have a separate SNAPSHOT site.
> >>
> >> Do we put this magic in commons-parent?
> >
> > I prefer the opposite - site is current dev.
>
> That is of little use to end users.
>

I think it is important that the site shows what is going on in the project
- that is *current dev*.  As long as end users can get the latest release
easily and the latest javadoc is linked, their needs are met and more
importantly if we keep the site up to date they can see *where the project
is going*.    I guess I see the site as more a *project site* rather than
an archive.   Our "end users" are developers and we want to encourage them
to get involved via the web sites.  That means putting documentation on the
latest, greatest, not-yet-released stuff up for them to look at.  I would
not be opposed to publishing a commons archive site somewhere if someone
wants to scratch that itch; but the component sites should not try to be
that, IMO.

>
> >  Download pages always reflect latest release (in some cases multiple).
>
> Agreed.
>
> > Last released javadoc must be linked.
>
> Agreed.
>
> > Older (released) javadoc is good to have, as is current dev javadoc.
>
> Agreed.
>
> > Old (released) user guide, etc is optional.
>
> Current (released) user guide etc is mandatory.
>

Well, we disagree here then.  We have never had the "requirement" before
and I am -1 to adding it now.

Phil

>
> > Phil
> >>
> >> Gary
> >>
> >>
> >>> On Sat, Jul 26, 2014 at 7:07 AM, sebb <sebbaz@gmail.com> wrote:
> >>>
> >>>> On 25 July 2014 18:03, Stefan Bodewig <bodewig@apache.org> wrote:
> >>>>> On 2014-07-25, Gary Gregory wrote:
> >>>>>
> >>>>> It's that or we agree never to publish a SNAPSHOT site.
> >>>
> >>> I don't see that as a strict dichotomy.
> >>>
> >>>> For the record, I do value SNAPSHOT sites so we can also show what we
> >>>> are working on.
> >>>
> >>> That does not necessarily need a whole snapshot site.
> >>> A news page would be sufficient in many cases.
> >>>
> >>>> I'm not convinced we need to enforce the same policy
> >>>> for all components.  OTOH I don't feel strong enough about it to
> really
> >>>> block a decision that discourages/prohibits SHAPSHOT sites.
> >>>
> >>> Agreed, so long as the SNAPSHOT site does not replace the site for the
> >>> release.
> >>> It's vital that users can easily get access to the docs for the
> >>> current release(s).
> >>>
> >>>> Stefan
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> Java Persistence with Hibernate, Second Edition
> >> <http://www.manning.com/bauer3/>
> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >> Spring Batch in Action <http://www.manning.com/templier/>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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