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 10 11 UI modules within ERM:

1. stripesFIRST: 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.

...

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

...

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. 
  7a. 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  7a.1.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
    7a.2b. 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.
  7b8. IfSelect github"Draft actionsnew arerelease" NOTfrom setgithub up foron the repository,right thehand NPM has to be built manually.
    7b.1. Navigate to https://jenkins-aws.indexdata.com/job/folio-org/job/ui-agreements/view/tags/ (assuming you are releasing the ui-agreements module)
    7b.2. 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) 
    7b.3. Once the build has started you can click the full stage view option to see the build
    7b.4. Wait for the build to be all done and green, then navigate to https://repository.folio.org/#browse/browse:npm-folio and see if your module has been published.
8. 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.
9. Paste the CHANGELOG for that module in the Describe this release section and click publish releasesid 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.

...

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