This document is a reference guide as to what steps are to be taken when relasing 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 UI modules within ERM:
- stripes-erm-testing
stripes-erm-components
- ui-handler-stripes-registry
- ui-plugin-find-agreement
- ui-plugin-find-eresource
- ui-plugin-find-license
- ui-dashboard
ui-agreements
ui-licenses
ui-local-kb-admin
- ui-erm-comparisons
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:
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.
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.
3) Manually browse through individual modules with the browser console open and ensure there are no glaring warnings/errors in the console.
4) 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 3 steps are done, edit the CHANGELOG (update the release date from In progress to the date of release). Example PR
At this point the modules are ready to be released
Release process:
Important note: Its mandatory that the stripes-erm-components needs to be the first 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.
7a. If repository has been set up with github actions, then the NPM should already be being built from the tag.
7a.1. Check the actions tab in the repository on Github, and find the task for the NPM release
7a.2. 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.
7b. If github actions are NOT set up for the repository, the 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 release
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