Release Checklist

To make sure all relevant activities are taken care of when we push out new releases, here are some checklists.

Bug fix release (e.g. 1.4.0->1.4.1)

Before tagging the release:

  • Build any compiled assets
  • Update the version number in the service class (core/components/package/model/package/package.class.php, setVersion line in the constructor)
  • Add the current date and new version number to the changelog
  • Go over the changelog. Is everything there? Will the changelog entries make sense to our users to understand what has been fixed? If not, add/edit the changelog.
  • Does any documentation need to be updated? New/changed snippet properties, improved behavior that may subtly change
  • Synchronise translations from CrowdIn using the command crowdin-cli download translations from the root of the project (ask Mark for the API Key)
  • Commit all changes from the items above.

Now you can tag the release. The command is git tag -a package-0.1.2-pl -m "Some helicopter-level summary". If you have GPG signing enabled (you should!), add the -s flag to also sign the tag.

Make sure all changes are pushed to GitHub. git push && git push --tags

After tagging the release:

  • Sync versions on the site. Login to the manager and go to modmore > Package Provider. Right click the package, choose Update Package, and then on the Versions tab hit "Synchronise Versions"
  • Clear the site cache
  • If the release is a pre-release (rc/beta) or for internal use only, edit the new version and set the channel appropriately.
  • With multiple versions with the same version but just a different release index (e.g. 1.2.3-rc1 and 1.2.3-rc2), the provider doesn't always understand what the latest is. Go to the main Package tab, choose the last version, and hit save.
  • On a dev/test/personal site, install the new update and give it a quick test.
  • Create a new thread on the Announcements & Security Notices board on the forum. Try to be creative, but always include the changelog of the new release.
  • Share the announcement on twitter from the official modmore account
  • Share the announcement on facebook from the official moreformodx page
  • If it's a noteworthy release, share it in #announcements on the MODX Community Slack
  • If you're not Mark, ask Mark to update the demo site. If you are Mark, reconsider your life choices that you still haven't automated updating the demo site.
  • Pop a bottle of champagne

For bug fix releases we don't generally do release candidates. If you're uncomfortable with some changes making its way to production sites, perhaps the release isn't ready yet? Or perhaps it's not just a bug fix release, but also contains new features or breaking changes that would put it in a different category?

Feature Releases

Before tagging a release

  • Build any compiled assets. Instructions for this depend on the extra and can typically be found under _build (e.g. Redactor)
  • Update the version number in the service class (core/components/package/model/package/package.class.php, setVersion line in the constructor)
  • Add the current date and new version number to the changelog
  • Go over the changelog. Is everything there? Will the changelog entries make sense to our users to understand what has been fixed? If not, add/edit the changelog. For feature releases there may be a lot of changes, split these up into New features, Improvements and Bug Fixes sections to make it easier to understand what's in the release. See the Changelogs wiki for more information.
  • Synchronise translations from CrowdIn using the command crowdin-cli download translations from the root of the project (ask Mark for the API Key)
  • Commit all changes from the items above.
  • Update the documentation. Think added/changed snippet properties, settings/configuration, new functionality, etc. The chances of a feature release having no impact on documentation is very slim, so if you don't think anything needs changing, you're probably overlooking something (or the release is not a feature release). Consider a special upgrade notes page for the release that explains how to use new or changed functionality on existing sites.
  • Decide if this needs to be a pre-release or not. See below.
  • Will this be the/a stable release? Coordinate marketing with Marc, ideally at least a week early so there's time to prepare a full announcement, work it into a newsletter if appropriate etc.

Pre-release or not?

For feature releases we may sometimes start with a pre-release cycle. The goal of a pre-release cycle is to lower the number of people that immediately start using a release to only the people that opted in to receiving the latest bleeding edge code. This can help iron out issues in new features.

Wether or not to do a pre-release cycle is a gut decision. Are there features in this release that might have an adverse result on existing sites? Are there changes which are very much "in your face"? On a scale of 1 to 10, how sure are you this release is not going to blow up?

If a pre-release cycle is in order, start with rc1 and plan it to take at least 2 weeks.

Tagging

Tag the release! The command is git tag -a package-1.4.0-rc1 -m "Some helicopter-level summary". If you have GPG signing enabled (you should!), add the -s flag to also sign the tag.

Make sure all changes are pushed to GitHub. git push && git push --tags

After tagging a release

  • Sync versions on the site. Login to the manager and go to modmore > Package Provider. Right click the package, choose Update Package, and then on the Versions tab hit "Synchronise Versions"
  • If the release is a pre-release (rc/beta) or for internal use only, edit the new version and set the channel appropriately.
  • With multiple versions with the same version but just a different release index (e.g. 1.4.0-rc1 and 1.4.0-rc2), the provider doesn't always understand what the latest is. Go to the main Package tab, choose the last version, and hit save.
  • On a dev/test/personal site, install the new update and give it a quick test.
  • If this is a pre-release:
    • Create a new thread on the Announcements & Security Notices board on the forum. Try to be creative, but always include the changelog of the new release. For the rc1 post, include a quick high level overview of what's new in the release and why people should be excited about it. Screenshots are nice for visual features. For a rc2 post or later, link back to the rc1 post.
  • If this is a stable release:
    • Coordinate with Marc for planned announcements to go out.
  • Share the announcement on twitter from the official modmore account
  • Share the announcement on facebook from the official moreformodx page
  • Share the announcement in #announcements on the MODX Community Slack
  • If you're not Mark, ask Mark to update the demo site. If you are Mark, reconsider your life choices that you still haven't automated updating the demo site.
  • Pop two bottles of champagne

Breaking release (e.g. 1.4.3->2.0)

Breaking releases might have a big impact on marketing, billing, licenses and other areas. There's no "one size fits all" checklist for that yet. Some high level questions to consider for breaking releases are:

  • Will it be a free upgrade for all users? If not, will it just be free for everyone with a subscription, or also for people who recently purchased a single license? How recently? What about people who have active support on the license? Some considerations that might be important are the desire for maintaining the old major release, the complexity of the upgrade for users, whether it's something existing clients will want to upgrade to (e.g. in some cases major upgrades may only complicate things on older sites), and if there have been any significant expenses related to the release.
  • How will the documentation of the old and new version be dealt with? Do we keep them both around as version-specific docs, or are there enough similarities that they can stay shared with some version-specific notes here and there?
  • Is it an actual breaking release or just a feature release that doesn't take backwards compatibility serious enough?
  • What do existing users need to change as part of the upgrade? Is the clearly described in the documentation?

Disclaimer: Viewing non-Euro pricing

You are currently viewing prices in a non-Euro currency. Please be advised that these prices are estimates, based on data by Open Exchange Rates.

While we offer this currency converter hoping our users find it convenient, all purchases are made in Euro, and the final amount charged can vary depending on payment provider, day, time of day and a number of other factors outside of modmore's control. There are no guarantees on accuracy and neither modmore nor Open Exchange Rates can be held liable for errors.

×