ERM UI modules release procedure

This document is a reference guide as to what steps are to be taken when releasing a UI module within ERM.

Note: The official stripes documentation is still the ultimate guide for the release procedure within FOLIO and should be understood well before releasing any modules.

Currently, we have 11 UI modules within ERM:

1. FIRST: stripes-erm-testing

2. SECOND:

   1. stripes-erm-components

   2. ui-handler-stripes-registry
3. THIRD: ui-service-interaction
4. FOURTH (in any order)
   1. ui-plugin-find-agreement
   2. ui-plugin-find-eresource
   3. ui-plugin-find-license
5. FIFTH (in any order)
   1. ui-dashboard

   2. ui-agreements

   3. ui-licenses

   4. ui-local-kb-admin

   5. ui-erm-comparisons
   6. ui-serials-management

We follow the FOLIO version-numbering scheme to version our apps/plugins. This is the same as the official semver documentation.

Note: Its imperative that the person releasing/maintaining the module needs to have a basic understanding of what major, minor, patch versions are and also understand the differences such as ^ vs ~ dependencies.

Its also important to understand the different types of dependencies that exist within the package.json. This is a good documentation that explains the different types of dependencies and their purposes.

Before you release (Pre-release process):

By this time, it is assumed that all your UI modules are synchronized with the released stripes version and you have also updated your UI modules to their respective major/minor version.

Next steps:

1) Run yarn lint acrosss all the modules and make sure there are no liniting errors or warnings.

2) Run yarn test across all the modules and make sure there are no test failures. (Note:  No tests for registry-handler)

3) Manually browse through individual modules with the browser console open and ensure there are no glaring warnings/errors in the console.

4) OPTIONAL (can be done during the actual release process):
Go through all the dependencies in the package.json and verify if all of the ones that require updation are updated (Note: Each of the erm UI modules depends on stripes-erm-components, so its important that each of those modules is dependent on  the version of stripes-erm-components that is going to be released)

5) Once steps 1-3 are done, edit the CHANGELOG . Example PR

1. Check release ticket (e.g. ERM-3101) for corresponding linked issues since last release date

2. Check filter page for each component,
   to find all related Issues, edit this JIRAsearch:

   project = erm AND resolution is not EMPTY AND resolution != "Cannot Reproduce" AND resolution != "Won't Do" AND resolutiondate >= 2023-10-20 AND component = stripes-erm-components ORDER BY created ASC

   1. update resolutionDate to last release date:

      If you filter by last release date you will find the last release Jira ticket and occassionally last tickets before release. Ignore the release tickets as well as backport tickets.
      You find the release date on github repository's sidebar under the Releases section as Latest tag.
      Example:

      
      Link example:
      https://github.com/folio-org/stripes-erm-components/releases/tag/v9.0.1

   2. update component
3. Check commit history since last release (from example), no translation or lokalise commits
4. OPTIONAL (if not done here, do it later at end of release process):
   update the release date from In progress to the date of release

6) Ensure LICENSE file has correct copyright year range (If range is 2020-2023 and it's 2024, update to 2020-2024 for example)

7) OPTIONAL (if pre-release and release process are done separately):

1. raise a PR when necessary
2. set the related Jira ticket from DRAFT to OPEN to indicate they are ready for any dependency changes and release completion

At this point the modules are ready to be released

Release process:

Important note: Its mandatory that the stripes-erm-testing needs to be the first module that has to be released if any changes have occurred. This is because all the other UI modules have a dev dependency on it and so the release task running the tests will fail for them if they can't find the expected stripes-erm-testing version from the https://repository.folio.org/#browse/browse:npm-folio repository.

Its mandatory that then stripes-erm-components needs to be the second module that has to be released. This is because all the other UI modules have a dependency on it and the build will fail for them if they can't find the expected stripes-erm-components version from the https://repository.folio.org/#browse/browse:npm-folio repository.

This logic also holds for the module ui-handler-stripes-registry  and any plugins used directly by our applications.

Suggested order is as listed above.

It may help to keep track of what is being released in a spreadhseet, such as this (shown example is from Nolana release):

Assuming, we are releasing version 3.0.0 for  a UI module and that you are on the up to date master branch for that module (at this point you have the CHANGELOG and probably package.json that are still uncommited):

1. git checkout -b 'v3.0'
2. git add package.json CHANGELOG.md
3. git commit -m 'Release 3.0.0'
4. git tag v3.0.0
5. git push --set-upstream origin v3.0
6. git push --tags
7. If repository has been set up with github actions, then the NPM should already be being built from the tag.
   (If github actions are NOT set up for the repository, the NPM has to be built manually, see below)
  a. Check the actions tab in the repository on Github, and find the task for the NPM release
  b. Once the action has passed, you can navigate to https://repository.folio.org/#browse/browse:npm-folio and see if your module has been published.
8. Select "Draft new release" from github on the right hand sid eof the repository page, and select your tag. Give it the name "Version x.y.z"
9. Paste the CHANGELOG for that module in the Describe this release section and click publish release
  a. If this is a full release or patch release in bugfest, select "latest release", otherwise make sure that is not selected
10. Send the release announcement to the #releases slack channel once done.

After the release:
1) Merge the branches pushed to github for the respectve modules into their masters
2) Bump the minor versions of all the UI modules with a new CHANGELOG version entry so that any new code being added doesn't accidentally go towards the just released version.

Note: Do not delete the branch you have just merged into the master as you can base off of these branches in case there is a requirement for a hotfix release.

For further information on the patch/hotfix release procedure refer to this section https://github.com/folio-org/stripes/blob/master/doc/release-procedure.md#patch-release-procedures from the official stripes release documentation.

FAQs:

todo