Description

This is our proposal for the release life cycle of Infinite Scale.

• With this proposal, we want to communicate what users can expect from Daily, Rolling and Production artifacts of Infinite Scale.
• In addition to improved communication and transparency, we want to encourage users to use the rolling release, so that we have a better feedback loop after each sprint.

Release Life Cycle for Infinite Scale

superseeds #6581

Comments

Audience for the Releases

ownCloud Infinite Scale will be released in three different release flavors in the future. Each of them is targeted to a specific use case and audience group:

• Daily: Mainly for test use cases. As the releases are done completely unattended, only the automatic test suite has tested the release. Manual testing was only applied by chance. Based on ownClouds strong test suite the daily releases are pretty stable, but the risk of unfinished changes is high. For example, if a feature requires three commits, and only one was committed, the daily is cut anyway.
• Rolling: Chances are high that some manual testing has happened, yet not structured. Features are mostly completed. An upgrade path from the previous rolling release is provided and tested. Great release to use with non critical data. Critical bugs are guaranteed to be fixed with the next rolling release.
• Production: Stable and tested release, suitable for critical data. Slow rolling, slow feature additions. Patch releases are provided for critical- and security-bugs as defined by ownCloud support regulations. Release dates are defined by ownCloud, and are not guaranteed.

Documentation

Production, will come with released documentation that is specific for the release. It will remain valid throughout the whole livetime of the release. If patches require documentation changes, addendums will be delivered.

Daily and Rolling have access to the documentation as it moves forward in the development process along with the product which will be available on ownClouds web site. There wont be specific releases. Changelog entries, PR comments and similar engineering output can complement the information.

Updating and Overlap

Daily does not come with any guaranteed update path. Chances are good that updates will go smooth, but that might have hickups in cases where the upgrade code is not finalized in time.

Rolling is guaranteed to upgrade from the last rolling release or from the previous daily before the new Rolling release. If a critical bug is found in a rolling release, it is guaranteed to be fixed in the next Rolling. There are no backports to the Rolling. In critical cases, an upgrade to a daily release in between has to be done at own risk.

Production provides a guaranteed upgrade path from the last Production release, as well as from the previous Rolling release before the new Production. For that, support from ownCloud is required. Upgrades between two Production releases are only supported to tested patch releases provided by ownCloud. In an upgrade process, all released patch releases have to be installed in the correct sequence.

Only production gives a reasonable overlap time between releases, for example if version 9 was released, version 8 will still receive a patch release for critical bugs for a reasonable time frame. That time frame will be announced separately and will be aligned with customer needs.

Support

ownCloud only offers commercial support for Production. Rolling might be considered for customer installations in the sales process but always requires an individual agreement between all parties.

Daily and Rolling are supported on best effort provided by community and ownCloud staff. There is no SLA and no guarantee for attention.

As ownCloud understands that the effort taken to report a problem is significant and results benefit all users in the community and ownCloud customers, there are resources available to respectfully work on community issues.

Please consider the Contribution guidelines for this.

Versioning

Semantic Versioning brings us these advantages:

• Predictability and Clarity
• Facilitates Dependency Management
• Supports Automated Tooling

Misinterpretation Problem
Major version changes are perceived as improvements (eg. iPhone 6 -> 7, Windows 10 - 11 ) but in semver Major version changes are actually bad, as they indicate incompatible API changes.

As a user who has not learned about semantic versioning, I want to quickly determine if I am using the current version, so that I can ensure I am not missing out on the latest features.