How to release

To release a new version of the salt-netapi-client, follow these steps:

• Checkout the master branch and pull latest changes: git checkout master && git pull.
• Edit pom.xml and set the <version> element to the upcoming release version (x.y.z).
• Edit README.md accordingly, i.e. replace the old version with the new version.
• Commit those two changes with one commit (e.g. Update version to x.y.z in pom.xml and README.md).
• Push this commit directly to master or create a PR (if review is wanted) and merge.
• Tag the new version referencing that commit in master and push the tag: git tag v[x.y.z] && git push origin v[x.y.z].
• Wait for the new release to be created by Travis, see Releases.
• Edit the release notes manually.
• Increase the version in pom.xml to the next *-SNAPSHOT and push the changes to master or create a PR for review.

Release to maven central (requires valid credentials for the ossrh server in ~/.m2/settings.xml):

• Use a fresh clone (use git clone) of the repo and checkout the version tag to be released: git checkout v[x.y.z].
• Run mvn clean deploy -Dtest=\!*DockerTest.java for deployment (excluding docker tests to run locally).
• Check staging repositories to verify the uploaded artifacts.
• Run mvn nexus-staging:release for release or mvn nexus-staging:drop to drop the deployment.

Update the RPM package:

• Branch the package from OBS.
• Checkout the branched package locally using osc co.
• Clone the package sources git repository.
• Get the new sources as tarball from Releases.
• Use tetra on the package sources to update the kit package, spec files and source archive.
• Sync back the results (package sources in ./packages) with OBS while updating the changelog (salt-netapi-client.changes).
• Make sure to remove patches from the package that are becoming obsolete with the new version.
• Commit the package to your branch (osc ci) and create an SR.
• Copy the package (osc copypac) to all relevant places, i.e. Head, 4.1 or 4.0, or create additional SRs accordingly.
• Commit back any changes that were made to the package sources.

Update other codebases (e.g. Uyuni):

• Implement a patch to update Uyuni to work with the newly released version of the library.
• This involves the removal of duplicated classes that were used for temporary fixes, making use of new library features, etc.
• Update the ivy file in master branch (./java/buildconf/ivy/ivy-suse.xml) according to the new version.
• For Manager-4.0 and older versions: extract the new jar file from the RPM and upload it to the ivy repo.