commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: Site Builds and Release Votes
Date Sun, 13 Oct 2013 19:26:30 GMT
The problem I'm seeing with deploying the side as needed is, that the
JavaDoc report will the so latest trunk and not the latest released API. In
[LANG] we have the link to the latest realese JavaDoc. Compress for example
has no such link. So a redeploy (for example to add some more
documentation) will override the JavaDoc report. This may confuse users.
In other words: if the site build and deploy is decoupled from releases,
there should be a link to the JavaDoc of the latest release.

Benedikt


2013/10/13 Henri Yandell <flamefew@gmail.com>

> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe <Luc.Maisonobe@free.fr
> >wrote:
>
> > Le 13/10/2013 17:35, Stefan Bodewig a écrit :
> > > Hi all
> > >
> > > in the recent release vote for Compress Gary and I had very different
> > > opinions on the importance of the site build for release candidates.
> > >
> > > On 2013-10-13, Gary Gregory wrote:
> > >
> > >> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig <bodewig@apache.org>
> > wrote:
> > >
> > >>> I have not created a RC website as the only difference to the current
> > >>> website would be the download page and the version number - and I'd
> > >>> immediately change the site after the release to include the release
> > >>> date anyway.
> > >
> > >> - Using the live site for the RC is a bad idea IMO because the source
> > >> will have to be changed to update the version, for example "The
> > >> current release is 1.5." and "Commons Compress 1.5 requires Java 5"
> > >> and who knows what else will have to be changed. This means that what
> > >> is in the RC is NOT building the 1.6 site, it is building a SNAPSHOT
> > >> site.
> > >
> > > To me creating the site is one of the completely unnecessary steps to
> > > perform when cutting a release candidate.  Building and uploading the
> > > site takes something > 15 minutes to me.  So far I have never published
> > > the RC site when the RC was accepted but rather created a new site
> build
> > > that contained the release date, updated the changes report with a
> > > placeholder for the next release and so on.
> > >
> > > We can - and should - update the site outside of any release anyway, so
> > > to me the site content is completely irrelevant when I evaluate
> > > releases.
> > >
> > > I'll admit that this mirrors my suspicion that nobody looks at the site
> > > build contained in the binary release anyway.  People use their
> > > dependency manager of choice and the online docs in my experience.
> > >
> > > How do others think about the release candidate site build?
> >
> > I agree the site build is orthogonal to release.
> > The main thing we release is source code. Then on top of that we add
> > some binaries, but it is already a by-product. The site itself is not
> > something we should consider to be in the scope of the release.
> >
> >
>  Agreed - the site build as a whole is for informative purposes during a
> vote. If there are any bugs in a site, they never block the release as they
> can be fixed out of band.
>
> The only items that should be blockers on the site build are those included
> in the distribution. I thought that was only the javadoc instead of the
> whole site? I'd definitely consider a bad javadoc to be something we should
> consider a new RC for, though it would depend on the severity. The cost of
> building a new RC is greater than fixing a typo in javadoc.
>
> Hen
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

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