Skip to end of metadata
Go to start of metadata

MidPoint Release Checklist

  1. Pre-release code changes:
    1. Switch off Wicket development mode (gui/admin-gui/src/main/webapp/WEB-INF/web.xml)
    2. Switch off checks in InternalsConfig
    3. Check versions of ConnId and the connectors. If there are any snapshorts then release these first and fix the versions.
  2. Pre-release check:
    1. Check Jenkins state
    2. Check that overlay projects work
    3. Check that WebLogic deployment works
    4. Check that dist package is built correctly, nothing is missing and that fresh midpoint starts
    5. Fresh clone/pull of the source code, fresh build (delete local maven repository before build). Run all tests. Make sure that the code is ship-shape.
    6. Run as standalone and test Tomcat deployment
    7. Check outstanding Jira issues
    8. Check that DB scripts are up-to-date
      1. ask someone to review the scripts
      2. check that there are no scripts for older releases
      3. check that config/sql/_all has both "create" and "upgrade" scripts for every database
    9. Check changes in init objects (admin-gui/src/main/resources/initial-objects).
      1. git log --stat gui/admin-gui/src/main/resources/initial-objects
      2. Document changes in release notes
      3. Copy the new objects into config/initial-objects
    10. Update README, NEWS, INSTALL, INSTALL-dist, RELEASE-NOTES
    11. Review Notice file, make sure all copyright notices are there
    12. Make sure there is enough space on website to hold the release
  3. Do the "source code" release:
    1. Change maven version to final (non-snapshot) version (see the use of "version" plugin below), e.g. mvn versions:set -DnewVersion=3.4
    2. Change maven version also in samples/model-client-sample, weblogic-build
    3. Change plugin dependency version in infra/schema/pom.xml, model/model-client/pom.xml (usually not needed any more)
    4. Check that there are no SNAPSHOT versions in pom.xml dependencies (find . -name "pom.xml" -exec grep SNAPSHOT {} \; -print)
    5. Change version in XSD schemas (especially common-*.xsd) - remove SNAPSHOT
    6. mvn versions:commit
    7. Clean local maven repo and rebuild with tests - to make sure nothing was broken by changing the version (for 3.4.x build with java7!)
    8. git commit
    9. Git tag: v3.4 (not midpoint-v3.4 !!!): git tag -a v3.4 -m 'Version 3.4 (VersionName)'
    10. Rebuild and package midpoint: mvn clean install package -DskipTests=true (Important! for 3.4.x build with Java7)
    11. Save the binary distribution for upload (important! build only after tagging, we need correct "git describe"):
      1. dist/target/midpoint-*-dist.*
      2. dist/midpoint-api/target/midpoint-api-3.4.jar
      3. dist/midpoint-api/target/midpoint-api-3.4-javadoc.jar
      4. infra/schema/target/schema-3.1-schemadoc.zip
    12. Generate full javadoc and save it
      1. mvn javadoc:aggregate-jar
      2. target/midpoint-3.4-javadoc.jar
    13. deploy midpoint (both standalone and tomcat), check that it starts OK, roughly test that GUI works
    14. Check that the version numbers are displayed correctly in the GUI (in "About")
    15. git push; git push origin v3.4
    16. Publish maven artifacts to nexus "releases" repository using mvn deploy -DskipTests=true (you need to have nexus username/password in maven settings.xml)
    17. Create a support branch, e.g. support-3.4 (if not created already): git checkout -b support-3.4; git push -u origin support-3.4; git checkout master
  4. Master branch
    1. Change maven version to next snapshot, e.g. 3.5-SNAPSHOT (also change in model-client-sample, plugins and others as described above)
    2. Change version in XSD schemas (especially common-*.xsd) - e.g. to 3.5-SNAPSHOT
    3. commit
    4. Tag the beginning of new development, e.g. v3.5devel (used in "git describe" strings): git tag -a v3.5devel -m 'Start of 3.5 development'
    5. git push, git push origin v3.5devel
    6. Update README and README.md to indicate development branch
  5. Support branch
    1. Change maven version to next support snapshot, e.g. 3.4.1-SNAPSHOT
    2. commit
    3. Tag the beginning of support, e.g. v3.4support
    4. git push, git push origin v3.4support
    5. Update README and README.md to indicate support branch
    6. Reconfigure bamboo support build plan
  6. Evolveum website:
    1. Upload binary distribution to Evolveum website (download section): dist/target/midpoint-* -> mercurius:/var/www/evolveum/downloads/midpoint/3.4
    2. Upload API javadoc to www:
      1. copy dist/midpoint-api/target/midpoint-api-3.4-javadoc.jar -> mercurius:/var/www/evolveum/downloads/midpoint/3.4
      2. mercurius: mkdir midpoint-api-3.4-javadoc; cd midpoint-api-3.4-javadoc; unzip ../midpoint-api-3.4-javadoc.jar
    3. Upload full javadoc to www:
      1. copy target/midpoint-3.4-javadoc.jar -> mercurius:/var/www/evolveum/downloads/midpoint/3.4
      2. mercurius: mkdir midpoint-3.4-javadoc; cd midpoint-3.4-javadoc; unzip ../midpoint-3.4-javadoc.jar
    4. Upload schemadoc to www:
      1. copy infra/schema/target/schema-3.4-schemadoc.zip -> mercurius:/var/www/evolveum/downloads/midpoint/3.4
      2. mercurius: mkdir schema-3.4-schemadoc; cd schema-3.4-schemadoc; unzip ../schema-3.4-schemadoc.zip
    5. Find someone to independently test the uploaded binary
    6. Update symlinks in /var/www/evolveum/downloads/midpoint/latest
    7. Update website links (download page, news, ...):
      1. Pages -> Download midPoint: add new row (and try not to get mad about row classes)
      2. Log out!
      3. Click through the website to verify it works.
  7. Update wiki links:
    1. Release notes (midPoint Releases): copy the "UNDER DEVELOPMENT" page to a next version, update the current version page
    2. Update midPoint History
    3. Update Roadmap
    4. Update Home
    5. Update SchemaDoc
    6. Update JavaDoc page
    7. Update Interfaces (each individual interface page)
    8. Update Identity Connectors if needed
    9. Update Script Expression Functions and subpages
    10. Update Configuration Samples
    11. Update Model Web Service Client Sample
  8. Update project versions in JIRA
  9. Update support branch name in Jenkins
  10. Update documents
    1. midPoint overview presentation
    2. datasheet
  11. Switch overlay sample projects to the released versions
    1. set versions, tag, push, ....
    2. update Customization With Overlay Project page
  12. Send announce to mailing list
  13. Write blog about new release

ConnId/Polygon Framework Release Checklist

  1. ConnId Java
    1. On a master branch run "git describe", remember the commit count number. (e.g. connid-1.4.0.0-49-g50340f7)
      WARNING! This is important to do "git describe" on the master branch. The number will be different on the evolveum_releases brach.
    2. Change to evolveum_releases brach
    3. git pull
    4. Merge in the branch that you want to release. Prefer version from master during conflicts. (git merge -X theirs master)
    5. Change maven version to final (non-snapshot) version. Use the number from git describe. (see the use of "version" plugin below), e.g. 1.4.0.49
    6. Check that there are no SNAPSHOT versions in pom.xml dependencies (find . -name "pom.xml" -exec grep SNAPSHOT {} \; -print)
    7. Clean local maven repo and rebuild with tests - to make sure nothing was broken by changing the version
    8. Commit
    9. Git tag: connid-1.4.0.49: git tag -a connid-1.4.0.49 -m 'Evolveum version 1.4.0.49'
    10. git push; git push origin connid-1.4.0.49
    11. Rebuild and package connid
    12. Publish maven artifacts to nexus "releases" repository using mvn deploy -DskipTests=true (you need to have nexus username/password in maven settings.xml)
    13. Switch back to master branch (git checkout master)
  2. .NET
    1. Use the same version as in the Java part (e.g. 1.4.0.49)
    2. Change to evolveum_releases brach
    3. TODO
    Polygon
    1. (ALT1) git checkout -b release-branch-1.4.0.49
    2. Edit top-level pom.xml, change connId.version to the version number used for ConnId release.
    3. Edit top-level pom.xml, change polygon.version to the version number used for ConnId release.
    4. Change version in connector-rest
    5. Change polygon version using mvn version:set. Use the same version as for associated ConnId release.
    6. Commit

    7. Git tag: v1.4.0.49: git tag -a v1.4.0.49 -m 'Version 1.4.0.49'

    8. git push; git push origin v1.4.0.49
    9. Rebuild and package
    10. Publish maven artifacts to nexus "releases" repository using mvn deploy -DskipTests=true (you need to have nexus username/password in maven settings.xml)
    11. (ALT1) git checkout master
    12. (ALT2) Change maven version to next snapshot, e.g. 1.4.1.0-SNAPSHOT
    13. (ALT2) Commit
    14. (ALT2) Tag the beginning of new development, e.g. v1.4.1.0devel (used in "git describe" strings): git tag -a v1.4.1.0devel -m 'Start of 1.4.1.0 development'
    15. (ALT2) git push; git push origin v1.4.1.0devel

Apache Directory API Release Checklist

  1. Pre-release check
    1. svn up
    2. mvn clean install
    3. Check bamboo state: Apache LDAP API, Connector LDAP, master_conntest
  2. Release
    1. NOTE: use Sun JDK7, not OpenJDK
    2. mvn versions:set -DnewVersion=1.0.0-M32-e1

    3. edit distributionManagement in pom.xml:

    4. disable tools-maven-plugin (otherwise there are "Artifact does not contain any legal files" errors) around line 494

    5. mvn clean install deploy

    6. DO NOT COMMIT!

    7. REVERT CHANGES: svn revert -R .

TODO: need to figure out how to save the (tagged) source code

Releasing a Connector

To release any connector:

  1. git pull
  2. Change the connector version in the pom.xml (e.g. 1.4.3.0-SNAPSHOT to 1.4.2.1)
  3. Build and test the connector
  4. Commit the change
  5. Create git tag: git tag -a v1.4.2.1 -m 'Version 1.4.2.1'
    List other tags to figure out when is the best tag format. Different connectors are using different conventions as they have different history.
  6. Push the changes: git push; git push origin v1.4.2.1
  7. Make sure that you have correct distributionManagement setting in your pom.xml (see below)
  8. Make sure that you have username and password in your settings.xml (see below)
  9. Deploy the connector to the Maven repository (nexus.evolveum.com) by doing: mvn deploy
  10. Change the connector version to the next development version in pom.xml (e.g. to 1.4.3.0-SNAPSHOT)
  11. Commit and push the change
  12. Update connector history on the connector page (e.g. LDAP Connector)

Misc

Changing Project Version

Use maven version plugin:

This will change main project versions and also versions in dependencies. However it will not change some version numbers in model-client/pom.xml which needs to be changed by hand.

If you are not happy with the versions, use revert instead of commit.

Distribution Management

When making unofficial release of foreign project, use this block in pom.xml to point to our maven repo:

Or, alternatively, use command-line property:

Also, those options may come handy:

 

Upload the artifacts to the maven repo using:

Maven Settings

The correct setting in the settings.xml file is needed to successfully deploy anything to the Evolveum Maven repository (nexus). The settings.xml file is usually in your home directory in the .m2 subdir ($HOME/.m2/settings.xml). It should look like this:

settings.xml

 

for 3.4.x

  • No labels