This is one of the caveat that I have when training people Maven usage and plugin configuration. The documentation is always the newest and it is actually hard to find old sites and the respective documentation.
The example I always use is the compiler plugin defaulting to language level 1.3 with 2.0 and then to 1.5 with e.g. 2.3.2 and e.g. only working nicely for Java 7 with the latest ones. Most people are NOT using the latest version of a plugin (although that is unfortunate) and have no good access to the documentation. So I would suggest to make it easier to find these old documentation sites instead of deleting them. Just my 2c though.. manfred On Mon, August 20, 2012 11:03 pm, Anders Hammar wrote: > My take: > > For people using an older version of a plugin, it's sometimes easier > to use the doc for that specific version. You will not be confused by > new features that aren't available in the version you're using etc. > BUT, that requires us to clearly publish links to each and every > version so they can use those. AFAIK we don't do that, so keeping the > older doc sites doesn't bring much value (today). But, who knows, > every now and then there might be someone that knows these links > (Maven devs?) that want to go back in time and remember the old good > days....:-) > > /Anders > > On Tue, Aug 21, 2012 at 12:42 AM, Hervé BOUTEMY <[email protected]> > wrote: >> I worked once again on updates on proposed release procedure when >> migrating to >> svnpubsub: >> http://maventest.staging.apache.org/developers/release/maven-plugin- >> release.html >> >> If we don't keep versioned documentation for each release, the procedure >> can >> be really simplified. >> And since documentation for most plugins and components is improved at >> each >> release, I'm asking for myself: should we really keep documentation for >> each >> and every release of anything (Maven core taken apart)? >> >> WDYT? >> Importing only latest version of everything would be a lot easier too, >> but >> since it is only to be done once, I can live with it. The real question >> is to >> choose if we want to keep every version? >> >> Regards, >> >> Hervé >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
