Roadmap

EPICS

Release preparation

key	summary	type	due	status

Loading...

Refresh

Modules release

key	summary	type	due	status

Loading...

Refresh

Timeline

May 13 2020 - API freeze for platform (Okapi/Stripes/RMB) readiness review. (RC review released platform components and facilitate meeting with unreleased components owners to discuss available impediments/issues/problems to understand when component could be released).
May 15 2020 - API freeze for platform (Okapi/Stripes/RMB) and deadline for initial releases of platform components.  No breaking changes to the platform after this date.
May 15 - June 12 2020 - Teams upgrade to the platform components versions that were released.
May 29 2020 – Review upgrade to platform components status. (RC review upgraded components and facilitate meeting with non-upgraded components owners to discuss available impediments/issues/problems to understand when component could be upgraded).
????? June 5 2020 – Modules development code freeze Q2 2020 ?????
8 June 2020 (Monday) Review modules release readiness. (RC review released modules and facilitate meeting with unreleased modules owners to discuss available impediments/issues/problems to understand when module could be released). Major interface version provided to be updated.
8 June 2020 – 12 June 2020 (Tuesday) Schema upgrade week. Major modules versions should be released. Schema upgrade have to be released and tested
<TBD> 9 June 2020 - Platform core modules release
11 June 2020 (Thursday) Schema upgrade review. RC review upgraded modules and facilitate meeting with non-upgraded modules owners to discuss available impediments/issues/problems to understand when schema could be upgraded.
12 June 2020 (Friday) Final Review modules release readiness. (RC review released modules and facilitate meeting with unreleased modules owners to discuss available impediments/issues/problems to understand when module could be released). Major interface version provided to be updated.
12 June 2020 (Friday) module release deadline — all modules must see Q2-compatible releases by this date
15 June 2020 (Monday) Contact with devops. Review release information. Up to date versions should be set
15 June - 22 June 2020 - Q2 release integration week
- Testing of schema and data migration
22 June - 10 July 2020 – Q2 2020 Release testing and hardening period:
- 22 June - 26 June 2020 Functional testing (Bug Fest) - Execute all TestRail test cases
- 22 June - 3 July 2020 Performance testing
- 29 June - 10 July 2020 Ongoing triage and bug fixing of bugs begins immediately
7 July 2020 (Tuesday) Bugfix releases readiness (RC review bugfix dashboard and facilitate meeting with unresolved modules owners to discuss available impediments/issues/problems to understand when module could be released).
10 July 2020 bugfix releases deadline
17 July 2020 release is public

Modules planned for release

Main release 12 June 2020

key	summary	assignee	status	development team	sprint	fixversions

Loading...

Refresh

Bugfix release 10 July 2020

Releases are deployed to bugfest https://bugfest-goldenrod.folio.ebsco.com/ twice everyday - 11AM and 4PM

Bugfix = a fix release that happens after the module release deadline, but before the actual release

Hotfix = a fix release that happens after the final flower release, and heads straight to production

This describes the Q3-2020/Honeysuckle Hotfix release process. This will be adjusted for future quarterly releases. (Prior quarters' Bugfix/Hotfix procedures are saved as child pages).

Hotfix release = one that must be added to a release after the final release has been made. As of July 20 2020, we are releasing hotfixes for Q1-2020 (Fameflower) and Q2-2020 (Goldenrod)
According to the soon-to-be-approved release process, we won't create a hotfix release except for P1 functional and P2 security issues. Once a hotfix release has been scheduled, lower priority issues (e.g. P2 and P3 functional issues) may also be included with permission.
For Q3-2020 hotfixes, set Release field of the bug Jira issues to Q3 2020 Hot Fix<Number> and make sure the developers doing the fix know that it is needed for a hotfix
Get the issue fixed and test on https://folio-snapshot.dev.folio.org/
Any hot fix issue should be approved:
1. Once the fix has passed testing in snapshot, post the Jira and seek approval for a hotfix release on the Slack #release_bug_triage channel. Approvers are Kelly Drake, Mike Gorrell, Harry Kaplanian, Holly Mistlebauer, Jakub Skoczen and Mark Veksler. Please tag the approvers with your request (can be considered approved if you get the thumbs up from at least two technical approvers (Mike, Mark or Jakub))
If approved, ask the module maintainer to create a hotfix release and set the JIRA status to Awaiting release.
1. You can get the module maintainer’s name from the Team Module Responsibility Matrix.
2. The release needs to go to the appropriate Release branch and the Main branch.
3. The release Jira should be linked to the appropriate Q3 2020 Hotfix epic, currently FOLREL-415
4. When the release is made, the module maintainer will announce it on the Slack #releases channel.
When the release is made, the module maintainer will announce it on the Slack #releases channel and change the JIRA status to Awaiting deployment
New for Q3 2020
1. The module maintainer will change the bug issue's status to Awaiting deployment. There is no need for the PO or module maintainer to request that the release be deployed
2. Jenkins robot automatically generate pull request for the "Q3 2020" branch of Platform Complete repository in Github for every released module if version incremented by "patch" number. (For example from 1.1.1 to 1.1.2)
3. Manual intervention required if release version requires change of major ( 1.1.1 to 2.0.0) or minor (1.1.1 to 1.2.0) number. In this case PO or Dev lead have to notify DevOps and Anton Emelianov (Deactivated) about this change.
4. Folio hosting team checks for updates of Platform Complete one time per day and updates Bug Fest system with modules that have been released since yesterday's update.
5. Folio hosting team will post notification in #bug-fest Slack channel when update starts and ends.
6. Once daily update has been deployed to Bug Fest, Anton Emelianov (Deactivated) will change the bug issue's status to In bugfix review which is the PO's trigger to do the final round of testing in the Bug Fest environment
7. Finally, when the issue has passed test in the Bug Fest environment, the PO should change the status to Closed
Add information about the hotfix to the Q3/Honeysuckle Release Notes page on the wiki, in the Post-release Hotfixes table: TBD
Once the hotfix has passed testing on BugFest, it needs to be deployed to libraries using the current release in production or in sandbox.
1. For EBSCO-hosted libraries, ask an EBSCO PO or Anton to deploy the fix.
2. For Index Data-hosted libraries, Wayne Schneider is managing the deployments.
3. Self-hosted libraries will need to decide whether to implement the hotfix or not, based on the announcement on the Slack releases channel or the Fameflower release notes.
If hotfixes are deployed by hosting providers, they should notify the libraries using the current release in production or sandbox that a hotfix has been deployed

This describes the Q3-2020/Honeysuckle Bugfix release process (fixes being released after the initial release, but before the final Honeysuckle deadline). This will be adjusted for future quarterly releases

Bugfix = fix that happens after the module release deadline, but before the actual release. Honeysuckle Release Schedule Most of these issues will be identified during BugFest Q3 2020 Honeysuckle BugFest
Set Release field of the bug Jira issues to Q3 2020 Bug Fix and let the developers doing the fix know that it is needed ASAP for a bugfix, definitely before the Goldenrod 17 July 2020 release. Do not confuse with the Fix version field, which should reflect the release version the fix will be included in.
Label the bug Jira issues with bugfest_q3.2020 if the bug is found by a community tester during BugFest (this allows us to keep statistics on the bugs produced during that process. Don't forget to link Jira issue to TestRail test case.
Use label regression when applicable
Get the issue fixed and test on https://folio-snapshot.dev.folio.org/ (if possible - some performance issues that don't repro on snapshot will have to skip snapshot testing and be tested on the Bug Fest environment, instead)
No permission is required for bugfixes before the release deadline. Once the fix has passed testing in snapshot, change the status to the "Awaiting release" and ask the module maintainer to create a bugfix release.
1. You can get the module maintainer’s name from the Team Module Responsibility Matrix.
2. The release needs to go to the appropriate Release branch and the Main branch.
3. When the release is made, the module maintainer will announce it on the Slack #releases channel.
Create a release ticket for the module and assign Epic FOLREL-414 - Getting issue details... STATUS . Be sure that each bug in the release has the correct release version assigned to it.
When the release has been created
Change the status of the release ticket to Closed
New for Q3 2020
1. The module maintainer will change the bug issue's status to Awaiting deployment. There is no need for the PO or module maintainer to request that the release be deployed
2. Jenkins robot automatically generate pull request for the "Q3 2020" branch of Platform Complete repository in Github for every released module if version incremented by "patch" number. (For example from 1.1.1 to 1.1.2)
3. Manual intervention required if release version requires change of major ( 1.1.1 to 2.0.0) or minor (1.1.1 to 1.2.0) number. In this case PO or Dev lead have to notify DevOps and Anton Emelianov (Deactivated) about this change.
4. Folio hosting team checks for updates of Platform Complete one time per day and updates Bug Fest system with modules that have been released since yesterday's update.
5. Folio hosting team will post notification in #bug-fest Slack channel when update starts and ends.
6. Once daily update has been deployed to Bug Fest, Anton Emelianov (Deactivated) will change the bug issue's status to In bugfix review which is the PO's trigger to do the final round of testing in the Bug Fest environment
7. Finally, when the issue has passed test in the Bug Fest environment, the PO should change the status to Closed

key	summary	assignee	status	development team	sprint	fixversions

Loading...

Refresh

Hotfix release

key	summary	assignee	status	development team	sprint	fixversions

Loading...

Refresh

Release notes

Q2 2020 (Goldenrod) Release Notes

Browser not supported