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: 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 Github Actions, 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):

• Important: make sure there is no local uncommitted changes in your repo using git status.
• Pull the latest changes 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 -DstagingRepositoryId=XXX for release or mvn nexus-staging:drop to drop the deployment.

Update the RPM package:

• Branch the package from OBS using either the Web UI or the osc branch command.
• Checkout the branched package locally using osc co.
• Download the new sources as tarball from Releases.
• Update the spec file, sources archive and changelog file locally.
• Make sure to remove any patches from the package that are becoming obsolete with the new version.
• Commit the package to your branch (osc ci) and create an SR (osc sr or Web UI).
• Copy the package (osc copypac) to all relevant places, i.e. Head, 4.3 or 4.2, or create additional SRs accordingly.

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.