On 1/5/14, 2:44 PM, sebb wrote: > On 4 January 2014 18:03, Phil Steitz <phil.ste...@gmail.com> wrote: >> On 1/4/14, 12:29 AM, Henri Yandell wrote: >>> To Sebb and Bendikt: >>> >>> I'm ambivalent on whether the reports are release version or snapshot, I >>> can see value in both (one encourages users, the other contributors). >>> However the site _has_ to be trunk. Having to do a new release just so we >>> can update the site doesn't strike me as healthy. >> +1 >> >> My NSHO here is that there is nothing wrong with the time-honored >> tradition here that >> >> a) the web site reflects *current development* - the reports, >> javadoc, text, examples, guides, whatever >> b) prior version javadocs are available linked on the web site >> >> As such, the web site should be updated / republished often. >> Ugliness in reports can encourage people to jump in and help out. >> Ugliness / incompleteness / obsolescence / mismatches with code in >> examples / text can encourage people to help out with >> documentation. As Hen keeps saying, the web site is never >> "released" and there should be no tight coupling between the web >> site and a specific release. (As a side note, when we began our >> decade-long love affair with maven site generation, we started the >> practice of including a link to the maven-generated site in release >> votes. The initial intent of this was just to validate that "maven >> site" actually worked - i.e., you could build a site locally from >> the source distro. That is all it has ever meant in my HO - we have >> never voted to "release" site content - just the source files that >> generate it.) > Including the site means that one can check basic things like the > front page/news section for typos etc. > >> The only loss here is users wanting definitive docs for the release >> versions they are using have only the javadocs immediately available >> on the web site. For most of our components, frankly you ain't >> getting much more than that. For the ones that have user guides / >> examples, I am more sympathetic to the view that these should be >> versioned / checked in like the javadocs. One day I may get >> motivated to set this up for the [math] user guide. > It's not just the Javadocs for the released software that are lost if > the website is updated with the trunk data. > > The Java Xref is also lost - it's really not that useful for trunk, as > users can just look at the current SVN source. > Whereas it is particularly useful for released versions, as I already > pointed out. > > There's also the Clirr report. > > Furthermore, if the website is updated with user guides for the new > features, it can be very confusing for users who find that the > software they have downloaded does not behave like the website seems > to say it should. > > If anything, it is the trunk documentation that should be relegated to > a subset of the website.
I guess we disagree with what the web site is for. I see it as the place to go to find out about the project - where the community is. It is *itself* a community product and *in development* along with the current actively developed code. > > Just imagine what it would be like trying to use Maven plugins if they > only showed the trunk behaviour. No comment ;) I don't think in any case this is a valid comparison, since the web site doco for the maven plugins is like our javadoc, which I agree should be versioned and available via the web site. > > The primary users of Commons components are people wanting to use the > components to build applications and systems. > They need to be able to find the information on releases easily. Yes, that is primarily the javadoc. Old user guides, etc., would be helpful, but as I said above, I don't see commons web sites as "definitive user guides" - they are informational sites about what is going on with the components. As a concrete example, I am going to start working on updating the DBCP docs for 2.0. Do you really think I should wait to publish this stuff until 2.0 is released? We want people to start playing with the new API, downloading nightlies or building snaps from source so we can get feedback. Tomcat 8 is *already shipping* this code. This is where the community should be focusing and what the web site should reflect. Phil > >> Phil >>> To Gary: >>> >>> It has two versions (source version and the generated version checked in), >>> but there's no reason either should be shown so prominently, if at all. >>> >>> Hen >>> >>> >>> On Fri, Jan 3, 2014 at 6:20 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >>>> But the site is versioned, in SVN and as a reflection of the SVN/release >>>> of the code base. >>>> >>>> G >>>> >>>> -------- Original message -------- >>>> From: Benedikt Ritter <brit...@apache.org> >>>> Date:01/03/2014 08:12 (GMT-05:00) >>>> To: Commons Developers List <dev@commons.apache.org> >>>> Subject: Re: [LANG] Snap-shot version in website header >>>> >>>> 2014/1/3 Henri Yandell <flame...@gmail.com> >>>> >>>>> Yes we change the site between releases. >>>>> >>>>> The bigger question is why we have a version number on the website, it >>>>> isn't versioned. >>>>> >>>> Well at least the repots have kind of a version, because they reflect the >>>> state of the code they were build against. >>>> And to me the reports for the latest release are far more important then >>>> those for the current trunk. >>>> >>>> >>>>> Hen >>>>> >>>>> >>>>> On Thu, Jan 2, 2014 at 6:45 AM, Duncan Jones <dun...@wortharead.com> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> The top of the commons-lang web page reads: >>>>>> >>>>>> "Last Published: 01 January 2014 | Version: 3.3-SNAPSHOT " >>>>>> >>>>>> Shouldn't that read: >>>>>> >>>>>> "Last Published: 01 January 2014 | Version: 3.2 " ?? >>>>>> >>>>>> Or are we changing the site between releases, thus necessitating that >>>>>> we build a site using the current (snapshot) version number? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Duncan >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>> >>>> -- >>>> http://people.apache.org/~britter/ >>>> http://www.systemoutprintln.de/ >>>> http://twitter.com/BenediktRitter >>>> http://github.com/britter >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
