Page Comparison

This document is a reference guide as to what steps are to be taken when relasing 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 9 11 UI modules within ERM:

1. FIRST: stripes-erm-testing

2. SECOND:

   1. stripes-erm-components

   2. ui-
   agreements

3. ui-licenses

4. ui-dashboard

5. ui-erm-comparisons

6. ui-local-kb-admin
   1. handler-stripes-registry
7. THIRD: ui-service-interaction
8. FOURTH (in any order)
   1. ui-plugin-find-agreement
   2. ui-plugin-find-
   agreement
   1. eresource
   2. ui-plugin-find-license
   ui-plugin-find-eresource
9. 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.

...

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 considered that all your UI modules are synchronized with the relased stripes version and you have also updated your UI modules to their respective major/minor version.

...

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 the above steps 1-3 steps 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:

   No Format
   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:

      Info
      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: Image Added 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) 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

...

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 first 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):

Image Added

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. Navigate to https://jenkins-aws.indexdata.com/job/folio-org/job/ui-agreements/view/tags/ (assuming you are releasing the ui-agreements module)
8. Login to jenkins and check for the 3.0.0 tag from the list (from the dropdown beside the tag, click the build now button) 
9. Once the build has started you can click the full stage view option to see the build
10If 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 buildaction is all done and greenhas passed, you can navigate to https://repository.folio.org/#browse/browse:npm-folio and see if your module has been published.
118. Navigate to https://github.com/folio-org/ui-agreements/tags and you should see the tag there. Click on it and draft a new release.
12Select "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
13", 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.

...

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