January 25, 2023
Hyrax Maintenance Working Group
A written policy prevents word-of-mouth policies which create confusion in the community. A written policy also provides a transparent way to communicate our values to people who may not work on the maintenance team consistently. It gives a basis to justify spending time on something that isn’t in the product backlog.
Updated versions of JavaScript libraries, Ruby, and Ruby gems are released all the time. If we don’t keep our applications up-to-date with the latest released versions of their dependencies, we may end up with applications that rely on dependencies with known vulnerabilities, bugs, or deprecated features.
Hyrax releases are managed in two groupings:
- Breaking changes which include new features with incompatible changes such as requiring data migration, bug fixes or security fixes with incompatible changes.
- Non-breaking changes which have new features that can be introduced with feature flipper, backwards compatibility, or that do not require data migration, bug fixes or security fixes that do not require data migration.
Hyrax follows semver for release versioning. All releases are handled in X.Y.Z format.
Current releases are at https://github.com/samvera/hyrax/releases
New features with incompatible changes such as requiring data migration, bug fixes or security fixes with incompatible changes. Breaking changes are paired with deprecation notices in the previous minor or major release.
New features that can be introduced with feature flipper, backwards compatibility, or that do not require data migration. May also contain bug fixes or security fixes that do not require data migration.
Bug fixes or security fixes that do not require data migration. No new features.
Supported versions are the highest currently released X version and then backwards to X-1. So when Hyrax 4.0 is released, the latest Hyrax 3.y is supported but Hyrax 2.y is not. Extended support for an otherwise unsupported version may be offered at the Product Owner or Technical Lead’s discretion. See End-of-Life Versions below.
New features that are added to the current release may be backported to supported past versions on a case-by-case basis. New features that are not relevant to the current release can be added to a supported past version.
Bug fixes that are added to the current release may be backported to supported past versions on a case-by-case basis.
The current major release will receive patches and new versions in case of a security fix. The last release in the previous major version will also receive security updates. So when Hyrax 4.y has a security fix applied, this security fix would also be applied to the latest Hyrax 3.y, but not to Hyrax 2.y.
Deprecated or end-of-life versions of dependencies used as part of building a Hyrax-based application will be removed from the test suite to manage maintenance. If an outdated version of a dependency is still supported that does not pose security issues, it may remain supported in the test suite.
End-of-life versions are X-1 versions behind the highest currently released X version. So when Hyrax 4.0 is released, Hyrax 2.y is end-of-life and no longer supported, but Hyrax 3.y is still supported and is not end-of-life. Extended support for an otherwise unsupported version may be offered at the Product Owner or Technical Lead’s discretion (e.g. many major releases in a short period of time). See Supported Versions above.
End-of-Life versions of Hyrax will not be supported. Applying fixes (security or otherwise) will be up to the implementing entity. We encourage updating to supported versions of Hyrax to receive updates and security fixes.