Skip to content

Latest commit

 

History

History
37 lines (28 loc) · 2.23 KB

deployment.md

File metadata and controls

37 lines (28 loc) · 2.23 KB
Raw

Deployment

For your first time, read the full details at http://sfdc.co/omakase-deploy. Then use these tips as a quick reminder.

Quick Tips

  1. Ensure all relevant changes are committed and pushed.
  2. To tag and bump the version, from the master branch run mvn release:clean release:prepare
    • You will be prompted for version numbers:
      • If this is the first version in a Salesforce major release, manually enter a version with the minor number incremented (see versioning notes below).
      • For patches and other continuing updates in the release, the defaults are fine.
  3. Ensure CI passes on github and everything looks good.
  4. Run mvn release:perform -P release to push to sonatype nexus and maven central.
  5. Update the dependency version in aura.
  6. Update the dependency version in core.

Versioning Notes

We use semantic versioning, but with some considerations for the Salesforce release cycle.

For the first commit in a Salesforce release it's recommended to manually increment the minor number (or the major number if the changes are not backwards compatible). This way, changes can be made in patch independently from main and life will be easy.

You can manually make this change in the pom.xml, do it as part of the release:perform step described above, or by running mvn versions:set -DnewVersion=1.2.3.

For example let's say prod is on 222, and the Omakase version in prod is 1.4.4, and the current pom has 1.4.5-SNAPSHOT. When making the first commit for 224, first manually change the version to 1.5.0-SNAPSHOT. Then you can continue with the above process as normal. Emergency fixes in patch can continue to be made under 1.4.x.

Backwards-incompatable and API-breaking changes should only be done in the next major Salesforce release, not in patch, and you must increment the major number manually.

Quick Links