Technical concept to provide Rolling Releases for ocis

[tbsbdr]

Description

details on: https://owncloud.dev/ocis/release_roadmap/

Technical concept

(outcome of the work in this story)

We will provide two different docker images and upload our artifacts to the download server in two different subfolders

Docker images

ocis tag	owncloud/ocis	owncloud/ocis-rolling
7.0.0	✅	✅
7.0.0-rc.1	✅	✅
6.0.0		✅
6.0.0-rc.1		✅
5.0.3	✅	✅
5.2.0		✅
5.1.0		✅
5.0.2	✅	✅
5.0.1	✅	✅
5.0.0	✅	✅

Download mirors

ocis tag	stable	rolling	testing	daily
7.0.0	✅	✅	❌	✅ and all commits to master
7.0.0-rc.1	❌	❌	✅	❌
6.0.0		✅	❌	✅ and all commits to master
5.0.3	✅	✅	❌	✅ and all commits to master
5.2.0		✅	❌	✅ and all commits to master
5.1.0		✅	❌	✅ and all commits to master
5.0.2	✅	✅	❌	✅ and all commits to master
5.0.1	✅	✅	❌	✅ and all commits to master
5.0.0	✅	✅	❌	✅ and all commits to master

Automation

• Tools like renovate should be able to distinguish between these two channels on docker releases

User Stories

• As an admin I want to deploy a rolling release of ocis so that I don't have to wait ~half a year for the latest features.

Value

• faster feedback cycle
• increase product quality

Acceptance Criteria

• way to separately consume rolling and production updates in an automated way (eg. via renovate, docker and/or semver)
  • github release artifacts
  • docker hub release artifacts
  • versioning scheme: update https://owncloud.dev/ocis/release_roadmap/
• decision: how do we handle reva and web in ocis (releases or commits?)
• have a plan whats needs or could be automated for efficient rolling relases (see also Improve handling of new environment variables in releases #9254 )

Definition of ready

• Everybody needs to understand the value written in the user story
• Acceptance criteria have to be defined
• All dependencies of the user story need to be identified
• Feature should be seen from an end user perspective
• Story has to be estimated
• Story points need to be less than 20

Definition of done

• Functional requirements
  • Functionality described in the user story works
  • Acceptance criteria are fulfilled
• Quality
  • Code review happened
  • CI is green (that includes new and existing automated tests)
  • Critical code received unit tests by the developer
• Non-functional requirements
  • No sonar cloud issues
• Configuration changes
  • The next branch of the ocis charts is compatible

[micbar]

@d7oc @wkloucek

Do you have any ideas to that?

Our first idea was:

Docker releases

• owncloud/ocis - will only receive production release tags
• owncloud/ocis-rolling - will also receive rolling release tags

Would that work for renovate & co?

[d7oc]

I think first I need an explanation what the term "Rolling Release" should mean for in this case or in detail how it should differ from a major/minor/patch release in currently.

Just to give my view: A Rolling Release for me is kind of a continuous build. So you build every day and what's on main is available as release.
Benefit:

• everybody can access the latest stuff
• less work in release process
  Downside:
• If automated tests don't catch a flaw it will be broken in the current release state as there is no human QA involved.
• Without a differentiation of major/minor/patch users will be surprised by API changes as they might appear at any time.
• No possibility to jump back to a previous rolling version as new versions usually replace the old ones instantly.

This definition leads to my first struggle. The plan has Rolling Releases every three weeks which is a long period. So what makes this kind of release period different from a normal one? With that big timespan you can also decide at the end of the three weeks, what kind of release it should be, so depending on the changes it will be declared major, minor or patch.

Regarding renovate: I don't see any big issue here as you still need to increase some number of the single packages. See e.g. Tumbleweed also still has versioned packages: https://ftp.uni-erlangen.de/opensuse/tumbleweed/repo/non-oss/noarch/.

This fact also brings me to another question: What is the reasoning for oCIS? I mean this release model is usually used for software assemblies such as linux distributions where you have different components on different versions and instead of defining the combination of component x y z in version a b c as release foo you have a continuously moving pointer for the combination of the components. Now when I look at oCIS I don't see this assembly or do we plan to also version the different services independently?

[micbar]

Rolling release is defined for ocis as 3 weekly sprint artifact.

please check out https://owncloud.dev/ocis/release_roadmap/ for the definition.

[micbar]

Our rolling release is following semver.

[micbar]

Consider it as a different „channel“

[micbar]

CX Team is asking a lot about „can we have a tag instead of latest?“

[micbar]

@wkloucek Can you post your opinion?

@d7oc got a wrong impression.

We want to create two different channels, both following Semver.

See my little example. It means that ocis 5.0.3 is "production" and the next release on that channel would be 7.0.0 with a supported upgrade path.

ocis version	owncloud/ocis	owncloud/ocis-rolling
7.0.0	✅	✅
6.0.0		✅
5.0.3	✅	✅
5.2.0		✅
5.1.0		✅
5.0.2	✅	✅
5.0.1	✅	✅
5.0.0	✅	✅

[wkloucek]

@wkloucek Can you post your opinion?

actually I have no different questions than @d7oc already raised

[wkloucek]

See my little example. It means that ocis 5.0.3 is "production" and the next release on that channel would be 7.0.0 with a supported upgrade path.

That sounds something similar to LTS versions eg. of like Ubuntu. Except that those non-LTS version of oCIS have no (paid) support at all!?

[micbar]

@tbsbdr @kulmann @dragotin @dragonchaser

The challenge for the dev team would be deprecations, because they would need to span only over "production" versions.

[micbar]

See my little example. It means that ocis 5.0.3 is "production" and the next release on that channel would be 7.0.0 with a supported upgrade path.

That sounds something similar to LTS versions eg. of like Ubuntu. Except that those non-LTS version of oCIS have no (paid) support at all!?

[micbar]

actually I have no different questions than @d7oc already raised

I think my picture answers all the questions. Are there still some left?

My biggest concern was "As a vendor I want to enable andministrators to choose to which release channel they want to subscribe with their automation tools (renovate etc.) to control the risk"

[TheOneRing]

I think the release cycle described in #9264 (comment) sounds reasonable.
Why would deprecation span over "production" releases?
I mean we could remove a feature in every single rolling release. It just means that the major version for the rolling release needs to be bumped.
You can only switch from rolling to production by upgrading to a bigger major version.
What we would need to ensure is that there is a migration path documented (or automated) if you migrate production from 5 to 7.

[micbar]

Seems that we can get to an agreement.

I will update the top post.

[d7oc]

Great release to use with non critical data.

and

Company support on special agreement with ownCloud

sounds like a mismatch to me.

[dragonchaser]

@tbsbdr @kulmann @dragotin @dragonchaser

The challenge for the dev team would be deprecations, because they would need to span only over "production" versions.

Not the deprecation is the problem IMHO, you can deprecate variables any time, but the removalVersion is the tricky part. As you may only remove with new LTS/Production versions.

[wkloucek]

As you may only remove with new LTS/Production versions.

Which is kind of contradictory of keeping those LTS / production version stable. Therefore everything "disruptive" should only be done on non LTS / non production versions, right!?

[dragonchaser]

Correct, what I meant was you can deprecate variables any time in the release process after an Production version has been released, but the removal may only happen before the next Production version is released so we can define clear migration paths.

[individual-it]

Proposal from the meeting on 5.6.2024:

• change .drone.star to push everything to owncloud/ocis-rolling
• change .drone.star to publish the binary everything to a new subfolder in the download mirror
• add a list of tags to .drone.env: PRODUCTION_RELEASE_TAGS=7.0.0,6.0,5.0.3 (in this example 5.0.3, 7.0.0 and ALL 6.0.x releases will be "production")
• in the release ticket add a new checkbox to edit the PRODUCTION_RELEASE_TAGS line if its supposed to be a production release
• change .drone.star to push only production releases to owncloud/ocis

[micbar]

Concept is done. Sprint task is done.

[kulmann]

What about web and reva? Do we have any requirements regarding versioning of those with respect to production vs. rolling releases?

[micbar]

Good question. In regards of reva I think we always need a tagged version for rolling releases. Production releases require a stable reva branch in addition.

Do you have suggestions for web releases?

[micbar]

Great release to use with non critical data.

and

Company support on special agreement with ownCloud

sounds like a mismatch to me.

Real Life Example

A public tender uses rolling releases during the testing and acceptance phase and switches to the next production release shortly before go-live.

Reasoning

If some project chooses rolling releases to be more agile, it needs to upgrade every three weeks. That is serving its purpose during early phases of a project and leverages quick turnaround times and feedback while developing new features in a efficient SCRUM flow.

As soon as a project is coming closer to broader use, the platform needs to be stabilized and updates are not desired to happen too often. In addition to that, frequent patch releases are very welcome to keep up with the available bugfixes and roll updates without friction.

[kulmann]

Good question. In regards of reva I think we always need a tagged version for rolling releases. Production releases require a stable reva branch in addition.

Do you have suggestions for web releases?

Actually the same. I'd release far more often with final tags according to semver. And for the releases that are being used in an ocis production release I'd create a stable branch in web.