I'm not sure exactly - I assumed it was useful only because it is incredibly useful for me :)
For example, I find this very useful: http://www.springsource.org/documentation Based on that page, I know exactly where to go for documentation related to the particular version of Spring I'm using. My .02, Les On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen <[email protected]> wrote: > On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <[email protected]> wrote: >> The way we did this for JSecurity was to publish each release's >> documentation to its own version specific directory. Then I'd use a >> symlink to point to the 'current' version and/or snapshot. I.E.: >> >> http://shiro.apache.org/site/current/api >> >> and in the site directory, you'd have the following directories: >> >> 0.9.2 >> 1.0.0 >> 1.0.3 >> 1.0.4-SNAPSHOT >> >> and each time we published something important, we changed 'current' >> symlink to point to the latest release - it was really nice. Can we >> still do this? Maybe not, but I'm just checking. Will this work? > > Yeah, we could. The symlink probably needs to be created manually (as > opposed to as part of site-deploy.. though with sufficient coding, > anything's possible). Do you have any idea how the users felt about - > were the older docs used at all, was there confusion about which docs > they are browsing etc? > > Kalle > > >> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen >> <[email protected]> wrote: >>> Thanks to Brian for detailed instructions. I'm familiar with staged >>> releases and Nexus so we should be able to get this done. I assume I'm >>> going to cut the release when the time comes unless somebody else >>> steps up :) >>> >>> Les, as Brian noted site's somewhat separate from the release but by >>> default it's published at release time. Basically we have two options, >>> either we publish just snapshots of the site (i.e. exactly one site >>> url) or a site per release (i.e. site/1.0.0) and single url for >>> snapshots, the latter can be achieved with profiles. Multiple archived >>> and released sites could be useful (but also confusing) for users when >>> we have multiple releases available, but just for simplicity's sake >>> I'd go with a single site url at first. The javadocs are in any case >>> deployed per released version. >>> >>> Kalle >>> >>> >>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <[email protected]> wrote: >>>> Hey Les, >>>> >>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood >>>> <[email protected]>wrote: >>>> >>>>> Hi Brian, >>>>> >>>>> > To get everything setup for a staging repository >>>>> > Create a sub task under: >>>>> https://issues.apache.org/jira/browse/INFRA-1896 >>>>> >>>>> Done: >>>>> >>>>> https://issues.apache.org/jira/browse/INFRA-2488 >>>>> >>>>> > After the deploy you need to close the staging repo, and promote it >>>>> >>>>> What do you mean by close the staging repo? Just ensure that the team >>>>> does not deploy to staging to prevent overwrites? >>>>> >>>> >>>> A single maven deploy is a bunch of stateless deploys so there is no way to >>>> know when maven is done deploying all the artifacts. So after you do a >>>> deploy you need to tell Nexus you are finished. This puts the repository >>>> in >>>> a read-only mode >>>> >>>> You could do this all from a maven plugin (but personally I like the UI for >>>> this): >>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html >>>> >>>> >>>>> >>>>> Also, once the artifacts are in staging, how is promotion done in >>>>> Nexus? I mean, let's say that the community votes to approve the >>>>> release. How do you propagate those voted-upon artifacts from staging >>>>> to the release repo? >>>>> >>>> >>>> The actual promoting is also just a couple clicks (or the plugin listed >>>> above) >>>> Upon promotion all the artifacts are moved into the release repository. >>>> (and >>>> corresponding metadata is merged i.e. maven-metadata.xml) >>>> >>>> >>>> >>>>> >>>>> Thanks for the pointers! >>>>> >>>>> - Les >>>>> >>>> >>> >> >
