MAY Lib Release Process » Historique » Version 2
Anonyme, 30/10/2014 13:31
| 1 | 1 | Anonyme | h1. MAY Component Library Release Process |
|---|---|---|---|
| 2 | 2 | Anonyme | |
| 3 | {{>toc}} |
||
| 4 | |||
| 5 | The component library is a set of projects containing component definitions and implementation to be reused. |
||
| 6 | They are available through Maven Central for [[MAY Maven Eclipse Setup|use with Maven]]. |
||
| 7 | |||
| 8 | h2. General Overview |
||
| 9 | |||
| 10 | h3. Phases |
||
| 11 | |||
| 12 | Releasing the components implies different phases: |
||
| 13 | # Preparing for the release |
||
| 14 | # Tagging the release on Mercurial |
||
| 15 | # Deploying the release on Maven Central |
||
| 16 | # Preparing the next development cycle |
||
| 17 | |||
| 18 | All of this is of course fairly automatised using Maven. |
||
| 19 | |||
| 20 | h3. Modules |
||
| 21 | |||
| 22 | The library is decomposed in several software modules (which are Maven projects): |
||
| 23 | * *fr.irit.smac.lib.may.parent*: it contains general Maven instructions shared by the other modules. It inherits from *fr.irit.smac.parent-central*, which contains instructions to release to Maven Central. |
||
| 24 | * *fr.irit.smac.lib.may.parent-speadl*: it contains general Maven instructions shared by other modules with SpeADL code in it. It inherits from *fr.irit.smac.lib.may.parent*. |
||
| 25 | * *fr.irit.smac.lib.may.common-interfaces*: it contains Java interface used in the components. |
||
| 26 | * *fr.irit.smac.lib.may.common-components*: it contains most of the reusable components. |
||
| 27 | * *fr.irit.smac.lib.may.ivy-distribution*: it contains components to build distributed architectures using the "Ivy software bus":http://www.eei.cena.fr/products/ivy/. |
||
| 28 | * *fr.irit.smac.lib.may.webservices*: it contains component to build architecture exposing functionality as webservices. |
||
| 29 | |||
| 30 | h3. Syntactical Version Numbering |
||
| 31 | |||
| 32 | The Maven artefact follows the Maven version numbering and it is stored in the *pom.xml* file of each project. |
||
| 33 | All are using the 3 digits "SemVer":http://semver.org/ system (Major.Minor.Patch). |
||
| 34 | |||
| 35 | For non-release (development versions), this is followed by the SNAPSHOT element (Major.Minor.Patch-SNAPSHOT) that is replaced with the compilation time and date on deployment. |
||
| 36 | |||
| 37 | h3. Semantic Version Numbering |
||
| 38 | |||
| 39 | The MAJOR and MINOR number follows the numbering of the MAY plugin as explained on that [[MAY Plugin Release Process|page]]. |
||
| 40 | The PATCH number changes for the rest. |
||
| 41 | |||
| 42 | h3. Example |
||
| 43 | |||
| 44 | For the sake of this guide, we will consider that we are releasing a new version numbered 3.4.0 (and thus we were developing 3.4.0-SNAPSHOT). |
||
| 45 | |||
| 46 | h2. Preparing for the Release and Tagging it |
||
| 47 | |||
| 48 | First, everything must be committed to Mercurial before doing the version update (this can be verified with @hg status@ before). |
||
| 49 | Let's say we just finished developing the 3.4.0-SNAPSHOT version and want to release the new 3.4.0 version. |
||
| 50 | |||
| 51 | h3. Updating the POM Files |
||
| 52 | |||
| 53 | We must update the POM files to reflect that, but do not touch the MANIFEST files: |
||
| 54 | <pre> |
||
| 55 | $ cd parent |
||
| 56 | $ mvn versions:set -DnewVersion=3.4.0 |
||
| 57 | </pre> |
||
| 58 | |||
| 59 | This is done from the parent directory and will impact all the modules. |
||
| 60 | |||
| 61 | h3. Tagging the Release |
||
| 62 | |||
| 63 | Now we commit these changes and tag them in Mercurial: |
||
| 64 | <pre> |
||
| 65 | $ hg commit -m "prepare for 3.4.0 release" |
||
| 66 | $ hg tag v3.4.0 |
||
| 67 | </pre> |
||
| 68 | |||
| 69 | The commit should only change the POM files, nothing else (this can be verified with @hg status@ before). |
||
| 70 | |||
| 71 | h2. Deploying the Release on Maven Central |
||
| 72 | |||
| 73 | Then, the release has to be deployed to Maven Central: |
||
| 74 | <pre> |
||
| 75 | $ cd ../ |
||
| 76 | $ mvn -P release clean deploy |
||
| 77 | $ mvn nexus-staging:release |
||
| 78 | </pre> |
||
| 79 | |||
| 80 | This will clean the sources, compile everything, create packages, install them in the local maven repository and finally deploy the *fr.irit.smac.may.speadl.parent* and *fr.irit.smac.may.speadl* modules to Maven Central. |
||
| 81 | |||
| 82 | Note that to deploy to Maven Central, it is needed to: |
||
| 83 | * Have a Sonatype JIRA account linked to "this ticket":https://issues.sonatype.org/browse/OSSRH-12012 as explained on "this page":http://central.sonatype.org/pages/ossrh-guide.html. |
||
| 84 | * Have a GnuPG key to sign the packages as explained on "this page":http://central.sonatype.org/pages/requirements.html and "this page":http://central.sonatype.org/pages/apache-maven.html. |
||
| 85 | |||
| 86 | The @-P release@ argument is important so that the deployed artefacts have a source and javadoc associated artefact and are signed as needed by Maven Central. |
||
| 87 | The @nexus-staging:release@ goal must be called to actually accept the deployment and release it on Maven Central: that last phase can also be done "trough the Nexus UI":http://central.sonatype.org/pages/releasing-the-deployment.html. |
||
| 88 | |||
| 89 | h2. Preparing the Next Development Cycle |
||
| 90 | |||
| 91 | Now everything is deployed, we can prepare the next development cycle by increasing the version to a SNAPSHOT one: |
||
| 92 | <pre> |
||
| 93 | $ cd ../parent |
||
| 94 | $ mvn -DnewVersion=3.4.1-SNAPSHOT |
||
| 95 | </pre> |
||
| 96 | |||
| 97 | And then, we can commit it and push all the changes we made: |
||
| 98 | <pre> |
||
| 99 | $ hg commit -m "increment to 3.4.1 development version" |
||
| 100 | $ hg push |
||
| 101 | </pre> |