midPoint
Page tree
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 (for 4.0.x check both Java8 and Java11)
    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. (for 4.0.x build with Java8)
    6. Run as standalone and test Tomcat deployment (for 4.0.x check both Java8 and Java11)
    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 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. Review Notice file, make sure all copyright notices are there
    11. Make sure there is enough space on website to hold the release
  3. Release companion projects:
    1. midpoint-localization
    2. midpoint-samples
  4. Do the "source code" release:
    1. Update README, NEWS, INSTALL, INSTALL-dist, RELEASE-NOTES
    2. Change maven version to final (non-snapshot) version (see the use of "version" plugin below), e.g. mvn versions:set -DnewVersion=4.1
    3. Change maven version also in samples/model-client-sample, weblogic-build
    4. Change plugin dependency version in infra/schema/pom.xml, model/model-client/pom.xml (usually not needed any more)
    5. Change version in build-tools/pom.xml
    6. Check that there are no SNAPSHOT versions in pom.xml dependencies (find . -name "pom.xml" -exec grep SNAPSHOT {} \; -print)
    7. Change version in XSD schemas (especially common-*.xsd) - remove SNAPSHOT
    8. mvn versions:commit
    9. Clean local maven repo and rebuild with tests - to make sure nothing was broken by changing the version (for 3.x and 4.0.x build with java8!)
    10. git commit
    11. Git tag: v4.1 (not midpoint-v4.1 !!!): git tag -a v4.1 -m 'Version 4.1 (VersionName)'
    12. Rebuild and package midpoint: mvn clean install package -DskipTests=true (Important! for 3.x and 4.0.x build with Java8)
    13. 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-4.1.jar
      3. dist/midpoint-api/target/midpoint-api-4.1-javadoc.jar
      4. infra/schema/target/schema-4.1-schemadoc.zip save as (rename) midpoint-4.1-schemadoc.jar
    14. Save full javadoc: (does not work for 3.x, needs rebuild with java11 for 4.0.x).
      1. dist/javadoc/target/javadoc-4.1-javadoc.jar save sa (rename) midpoint-4.1-javadoc.jar
    15. deploy midpoint (both standalone and tomcat), check that it starts OK, roughly test that GUI works
    16. Check that the version numbers are displayed correctly in the GUI (in "About")
    17. git push; git push origin v4.1
    18. Publish maven artifacts to nexus "releases" repository using mvn deploy -DskipTests=true (you need to have nexus username/password in maven settings.xml)
    19. Create a support branch, e.g. support-4.1 (if not created already): git checkout -b support-4.1; git push -u origin support-4.1; git checkout master
  5. 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. Update README and README.md to indicate development branch
    3. Change version in XSD schemas (especially common-*.xsd) - e.g. to 3.5-SNAPSHOT
    4. commit
    5. 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'
    6. git push, git push origin v3.5devel
    7. Update database schema version in the initialization SQL files, e.g. INSERT INTO m_global_metadata VALUES ('databaseSchemaVersion', '4.1');
  6. Support branch
    1. Change maven version to next support snapshot, e.g. 3.4.1-SNAPSHOT
    2. Update README and README.md to indicate support branch
    3. commit
    4. Tag the beginning of support, e.g. v3.4support
    5. git push, git push origin v3.4support
    6. Reconfigure jenkins support build plan
  7. Evolveum website:
    1. Upload binary distribution to Evolveum website (download section): dist/target/midpoint-* -> static.artefacts:/var/www/download.evolveum.com/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. server: 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. server: 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. server: mkdir midpoint-3.4-schemadoc; cd midpoint-3.4-schemadoc; unzip ../midpoint-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.
  8. Update wiki links:
    1. Release notes (midPoint Releases): copy the "PLANNED" 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
  9. Update project versions in JIRA
  10. Update support branch name in Jenkins
  11. Update web and documents
    1. midPoint overview presentation
    2. datasheet
  12. Send announce to mailing list
  13. Write blog about new release
  14. Follow-up releases:
    1. Overlay projects
      1. set versions, tag, push, ....
      2. update Customization With Overlay Project page
    2. Docker image
    3. midpoint-client-java
    4. Eclipse plugin

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:

      <distributionManagement>
	<repository>
		<id>evolveum-nexus</id>
		<name>Internal Releases</name>
		<url>http://nexus.evolveum.com/nexus/content/repositories/releases/</url>
	</repository>
	<snapshotRepository>
		<id>evolveum-nexus</id>
		<name>Internal Snapshots</name>
		<url>http://nexus.evolveum.com/nexus/content/repositories/snapshots/</url>
	</snapshotRepository>
</distributionManagement>

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

      <plugin>
   <groupId>org.apache.geronimo.genesis.plugins</groupId>
   <artifactId>tools-maven-plugin</artifactId>
   <configuration>
     <strict>false</strict>
     <skip>true</skip>
     <requiredFiles></requiredFiles>
   </configuration>
</plugin>

    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:

mvn versions:set -DnewVersion=1.0.3-SNAPSHOT
[... check that the code bulds OK ...]
mvn versions:commit 

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:

    <distributionManagement>
        <repository>
            <id>evolveum-nexus</id>
            <name>Internal Releases</name>
            <url>http://nexus.evolveum.com/nexus/content/repositories/releases/</url>
        </repository>
        <snapshotRepository>
            <id>evolveum-nexus</id>
            <name>Internal Snapshots</name>
            <url>http://nexus.evolveum.com/nexus/content/repositories/snapshots/</url>
        </snapshotRepository>
    </distributionManagement>

Or, alternatively, use command-line property:

mvn clean install package deploy -DskipTests=true -DaltDeploymentRepository=evolveum-nexus::default::http://nexus.evolveum.com/nexus/content/repositories/snapshots/
mvn clean install package deploy -DskipTests=true -DaltDeploymentRepository=evolveum-nexus::default::http://nexus.evolveum.com/nexus/content/repositories/releases/

Also, those options may come handy:

-Dcheckstyle.skip=true -Ddisable.checks=true


Upload the artifacts to the maven repo using:

mvn clean install package deploy -DskipTests=true

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
 <settings>
  <servers>
    <server>
      <id>evolveum-nexus</id>
      <username>deployment</username>
      <password>XXXXXXXXXXXXXX</password>
    </server>
  </servers>
</settings>


for 3.4.x

  • No labels

Copyright (c) 2011-2019 Evolveum s.r.o. and Contributors