You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by br...@apache.org on 2005/03/04 05:51:23 UTC
svn commit: r156131 - in maven/maven-1/core/trunk/xdocs: start/adapting.xml
using/releasing.xml
Author: brett
Date: Thu Mar 3 20:51:20 2005
New Revision: 156131
URL: http://svn.apache.org/viewcvs?view=rev&rev=156131
Log:
making releases
Modified:
maven/maven-1/core/trunk/xdocs/start/adapting.xml
maven/maven-1/core/trunk/xdocs/using/releasing.xml
Modified: maven/maven-1/core/trunk/xdocs/start/adapting.xml
URL: http://svn.apache.org/viewcvs/maven/maven-1/core/trunk/xdocs/start/adapting.xml?view=diff&r1=156130&r2=156131
==============================================================================
--- maven/maven-1/core/trunk/xdocs/start/adapting.xml (original)
+++ maven/maven-1/core/trunk/xdocs/start/adapting.xml Thu Mar 3 20:51:20 2005
@@ -1,7 +1,7 @@
<?xml version="1.0"?>
<!--
/*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -66,7 +66,6 @@
projects</a> that can be used as references. However, it is worth checking more than one and referring to the
<a href="../using/bestpractices.html">Best Practices</a> document as you do this.
</p>
- <p>...</p>
</section>
</body>
Modified: maven/maven-1/core/trunk/xdocs/using/releasing.xml
URL: http://svn.apache.org/viewcvs/maven/maven-1/core/trunk/xdocs/using/releasing.xml?view=diff&r1=156130&r2=156131
==============================================================================
--- maven/maven-1/core/trunk/xdocs/using/releasing.xml (original)
+++ maven/maven-1/core/trunk/xdocs/using/releasing.xml Thu Mar 3 20:51:20 2005
@@ -1,7 +1,7 @@
<?xml version="1.0"?>
<!--
/*
- * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2001-2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -26,8 +26,117 @@
<body>
<section name="Making Releases">
- <!-- TODO -->
- <p>...</p>
+ <p>
+ Maven can simplify several areas of the release process for software, but it is always worth having a process
+ in order.
+ </p>
+ <subsection name="Determine Format">
+ <p>
+ Firstly, you must decide what format you will be distributing your software in. For example:
+ </p>
+ <ul>
+ <li>Standalone library</li>
+ <li>Binary and source distributions</li>
+ <li>Installer</li>
+ </ul>
+ <p>
+ If you are distributing your artifact as is, you can use the existing deployment goals (as discussed in
+ <a href="../reference/internal-repositories.html#Deploying_to_the_Internal_Repository">Deploying to the
+ Internal Repository</a>).
+ </p>
+ <p>
+ For binary and source archives, see the
+ <a href="../reference/plugins/dist/">distribution plugin</a>.
+ For installers, currently, Maven only supports the NSIS installer on Windows.
+ See the
+ <a href="../reference/nsis/">NSIS plugin</a> for information.
+ In both cases, some configuration will be necessary. You may have to do additional scripting to get the
+ release just as you want it.
+ </p>
+ <p>
+ Once you have decided on one or more formats and have tested being able to generate a release, you are ready
+ to go, and this won't need to be changed in the future.
+ </p>
+ </subsection>
+ <subsection name="Check Dependencies">
+ <p>
+ A key step towards making a release in Maven is to verify that your build is going to be reproducible (see
+ <a href="bestpractices.html#Reproduciblity">Best Practices</a> for more).
+ </p>
+ <p>
+ You should check the dependencies of the project you will be releasing to ensure that all dependencies on
+ snapshots or other non-final releases are resolved to proper releases and that the software is tested against
+ them.
+ </p>
+ <p>
+ If you remain pointing to a development dependency that is later overwritten, attempting to rebuild your
+ release may lead to at best a different result, at worst a failure to build.
+ </p>
+ <p>
+ If there is no release of the software, but you know the current development build to be stable, as a last
+ resort you should internally release that library, using the current time as a version, or similar that will
+ not be overwritten.
+ </p>
+ <p>
+ Future Maven release tools will help to identify the existence of such snapshots and help to resolve them,
+ in particular where they are your own and you are simultaneously releasing a set of projects.
+ </p>
+ </subsection>
+ <subsection name="Utilise Source Control">
+ <p>
+ If you are using a source control system, make sure to tag the release so that it can be built cleanly from
+ the system. Maven can provide assistance with this.
+ </p>
+ <p>
+ Currently, the only automated release mechanism in Maven is that provided by the SCM plugin.
+ Please refer to the documentation on
+ <a href="../reference/plugins/scm/releasing.html">Making Releases from SCM</a>.
+ </p>
+ <p>
+ The SCM plugin performs a release in two steps:
+ </p>
+ <ol>
+ <li>preparation - where the descriptors are updated, committed and the code is tagged</li>
+ <li>performing - where the code is checked out from the SCM cleanly and built from scratch, then released
+ using the distribution goals you selected in the first section.</li>
+ </ol>
+ </subsection>
+ <subsection name="Perform the Release">
+ <p>
+ With everything together, performing the release is quite simple. If the plugin supports it, you can deploy
+ the released artifact directly to the repository.
+ </p>
+ <p>
+ As discussed previously, if you are using an SCM, you should utilise the SCM plugin to do this, as it will
+ build in a clean checkout. Ideally you should also build in a known environment each time.
+ </p>
+ <p>
+ While Maven will currently deploy an MD5 checksum along with your distribution, this is only used to verify
+ download integrity. In many environments where there is public distribution over the internet, it is
+ recommended that additional security be put in place to verify the authenticity of the release.
+ </p>
+ <p>
+ While Maven does not currently support automatically generating it, it is recommended that you sign your
+ release using GPG, and provide the original signatures only on the tightly secured central server, instead of
+ on distribution mirrors.
+ </p>
+ </subsection>
+ <subsection name="Republish the Site">
+ <p>
+ As part of the deployment, you might want to republish your Maven generated web site with the new release
+ information, download links and release notes.
+ </p>
+ </subsection>
+ <subsection name="Announce the Release">
+ <p>
+ Finally, after the release is out, checked, and propogated to the mirrors, you will want to make announcements.
+ </p>
+ <p>
+ If you are maintaining a change record, you can use the
+ <a href="../reference/plugins/announcement/">Announcement plugin</a> to generate a plain text announcement
+ "release notes" style announcement and have it mailed to an announcement or other mailing list.
+ </p>
+ </subsection>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org