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 >>>> >>> >> >
