Provide "fresh" update channel

[ghost]

As seen in #25632 people are again struggling with the release channels / policy of ownCloud.

Currently it seems that 9.1.0 is provided within the "beta" channel. However "beta" is probably the wrong channel and misleading from the name so i'm suggesting to add an additional release channel for new major releases. From the naming maybe "fresh" is matching here so we could have:

• daily -> Daylies from master
• beta -> Real "betas" or "RCs" for the current major release, e.g. oC 9.1.1 RC1
• fresh -> Current major release, e.g. oC 9.1.0 (the best to have it instantly there to make the impatient people happy)
• stable -> Current previous major release, e.g. oC 9.0.4 (could be also current major release (e.g. 9.1.1 or 9.1.2 once it is stable enough)
• production -> Like "oldstable" in debian, e.g. oC 8.2.7

With that even the impatient people should be happy.

[PVince81]

@VicDeo @danimo what do you think ?

[PVince81]

and @dragotin

[VicDeo]

@PVince81 @RealRancor From my POV the channels need to be aligned with https://github.com/owncloud/core/wiki/Maintenance-and-Release-Schedule
somehow so I think one channel is not enough.

Having it as suggested:
9.1 fresh
9.0 stable
8.2 production

we are forcing 8.0 -> 8.1 -> 8.2 migration implicitly.
It happens because still maintained 8.0 and 8.1 have no room in this concept.
And it's quite common to have 5 releases that are being maintained simultaneously...

[ghost]

@VicDeo One step after another :-) From my PoV a fresh channel would solve quite a lot of complains of the community which is e.g. still wait for oC 9.1 via the updater app.

[ghost]

Ah, 8.0 could be released as "oldoldstable" and 8.1 as "oldstable". But i still think that five supported releases are a little overkill.

[hodyroff]

@pmaier1 need to redisign and solve this. In this description stable and production is pretty identical for me. and x.x.0 release is indeed a "fresh" one, so that's kind of a great name. Fresh then would mean that upgrades and full production usage is not yet recommended and should just be a rename of the current stable maybe?

daily -> Daylies from master
beta -> Real "betas" or "RCs" for the current major release, e.g. oC 9.1.1 RC1
fresh -> Current major release, e.g. oC 9.1.0 (the best to have it instantly there to make the impatient people happy)

production -> Current previous major release, e.g. oC 9.0.4 (could be also current major release (e.g. 9.1.1 or 9.1.2 once it is stable enough)

---

When we do that, should we also have an old-production for the eg. 8.2 release? This has advantages and disadvantages as really people should upgrade once production readiness is reached.
Do we need to open another discussion round on central?

[pmaier1]

I just had a long conversation with @jnweiger about this. Our proposal is as follows:

We stay with four release channels

• daily
• beta
• fresh (formerly 'stable')
• production

and maintain the following workflow (example with 9.1)

• daily builds from master
  [1] -> at some point: Decision to go beta 9.1.0
  [2] -> at some point: Decision to go beta 9.1.1
  [3] -> at some point: Decision to go beta 9.1.2
  [4] -> at some point: Decision to go beta 9.1.3
• beta
  [1] (9.1.0-beta1, 9.1.0-beta2, 9.1.0-RC1 etc.)
  -> at some point: Decision to release 9.1.0
  [2] (9.1.1-beta1, 9.1.1-beta2, 9.1.1-RC1 etc.)
  -> at some point: Decision to release 9.1.1
  [3] (9.1.2-beta1, 9.1.2-beta2, 9.1.2-RC1 etc.)
  -> at some point: Decision to release 9.1.2
  [4] (9.1.3-beta1, 9.1.3-beta2, 9.1.3-RC1 etc.)
  -> at some point: Decision to release 9.1.3
• fresh
  [1] fresh (9.0.latest -> 9.1.0)
  [2] fresh (9.1.0 -> 9.1.1)
  -> now: Decision -> is 9.1.1 production ready? -> no
  [3] fresh (9.1.1 -> 9.1.2)
  -> now: Decision -> is 9.1.2 production ready? -> yes
  [4] fresh (9.1.2 -> 9.1.3)
  -> now: since [3] 9.1 is production -> all following minors directly go to 'fresh' and 'production'
• production
  [1] (9.0.latest)
  [2] (9.0.latest)
  [3] (9.1.2)
  [4] (9.1.3)

This way we always provide a 'latest' channel for community (fresh) and are able to decide (and justify!) which minor release makes a major release production-ready.
For Enterprise we would only provide 'daily', 'beta' and 'production' channels (separate from community, of course). 'Production' behaves like the community channel: It stays at the previous major until the current major is decided to be production-ready in community 'fresh'. So testing for enterprise may occur with 'daily' and 'beta', productive systems only run with 'production'.

Another question is if we want to provide an 'old stable' channel for 8.x in the above example. I would make it dependent on enterprise usage and version support since community will mainly be on 'fresh' or 'production'.

What do you think about this? @RealRancor @PVince81 @hodyroff
@jnweiger Please correct me if I explained something incorrectly or add if I missed something. ;)

[PVince81]

This looks good yes.

But it reminds me that the web updater channels are inconsistent with the ones from distro packages.
Ideally we should unify them all, so the version paths you described above must be applied to all update methods at the same time (distro package repos, web updater, website?, etc).

[jnweiger]

@pmaier1 we should have a graphical representation. I mostly understand your tabular description, but I need the whiteboard behind me for the context.... :-)

One interesting artefact of that is: the community release process is now very close to the enterprise release process. the only difference is, that for enterprise there is no stable(fresh). For enterrpise we keep the X.X.0 releases in 'beta'. The jump from community stable(fresh) to commuity production would correspond to the announcement of the first enterprise ('production') release for a new X.X channel.

@PVince81 currently the version.php of 9.1.2 ce says 'stable' and the version.php of 9.1.2 ee says 'production'. Is that what you mean 'not in sync' or is that something different?

[PVince81]

Yeah, the "stable" channel for distro packages might not have the same level version as the "stable" channel in the web updater.

[bcutter]

I´m pretty sure I´m not at the right point here - doesn´t matter, point me to it.

Why the hell are we still stuck on 9.1.2(.5) instead of 9.1.4 or at least 9.1.3 which was released THREE MONTHS AGO?

It´s even not a good sign for itself being forced as a security interested "normal OwnCloud user" to search for reasons on a developer platform. There´s just no communication. No reason. No solution. Very frustrating. See it from the user´s side!

[pmaier1]

@bcutter

I´m pretty sure I´m not at the right point here - doesn´t matter, point me to it.

Correct. The right place to ask is the ownCloud community forum on central.owncloud.org.

Why the hell are we still stuck on 9.1.2(.5) instead of 9.1.4 or at least 9.1.3 which was released THREE MONTHS AGO?

I'm very sorry you ran into problems with oC though I don't understand your issue. Currently the latest oC server version is '9.1.4' which is available on the public repos and can be deployed following the guidance here.
If you have further questions please explain in detail on Central, I'm sure you will find help there!

[PVince81]

@pmaier1 this is about the web update server, the one that delivers update for tarball installs and allows with "one-click" update.

The update server has been deployed yesterday for all updates before 9.1: owncloud/administration#108

For 9.1.4 there are additional update issues when updating with this method: owncloud/administration#111

[ghost]

Correct. The right place to ask is the ownCloud community forum on central.owncloud.org.

The community can't be asked to make update notifications and updates available. This is the job / responsibility of you guys here. 😉

Furthermore this is also not only about the updater app but also about the update notification itself. You don't even tell the people that 9.1.4 is available (see e.g. #24827) or:

-> https://central.owncloud.org/t/ldap-backend-calendar-sharing-not-working/6360/3

So as long as you're silently not delivering the updates via the updater app you also don't tell the people that a newer version is available for manual installation (you can't expect that people are watching release notifications at owncloud.org or at central).

[PVince81]

The community can't be asked to make update notifications and updates available.

Yes, that is correct.

The first step was done to make the update server code public here: https://github.com/owncloud/administration/tree/master/update-server

This means that now community people could submit PRs to enable the update and also help testing locally. But the actual deployment still needs to be done by us.

The update notification that can be seen in the screenshot above is directly linked to what the update server delivers.

So maybe that notification needs to be split into two to also let people know that they can manually update with tarballs even if the update server isn't providing that version yet ?

[ghost]

So maybe that notification needs to be split into two to also let people know that they can manually update with tarballs even if the update server isn't providing that version yet ?

IMHO that would be a HUGE step forward and could solve at least the issue that people are thinking they are at a stable / latest release even if newer versions are available.

[hodyroff]

Thanks @kdslkdsaldsal this needs fixing ASAP. Splitting however is not possible this week. We will find a way to publish the 9.1.4 update to make people upgrade. -> @jnweiger

[PVince81]

We can publish the update right away, people will be able to deal with this minor issue about a stray file: owncloud/administration#111 (comment).

[luckydonald]

My OC 8.2.7 displayed "Your version is up to date".

Awesome. No need to update, no need to worry.

---

Maybe just let the update check for old system fail?
So users can see something isn't right?

---

#24827 (comment)

[VicDeo]

Certificate is valid https://www.ssllabs.com/ssltest/analyze.html?d=updates.owncloud.com&latest
https://updates.owncloud.com/server//?version=8x2x7x0x5x6xstablexdailyxdas
Response is

<owncloud>
<version>8.2.10</version>
<versionstring>ownCloud 8.2.10</versionstring>
<url>
https://download.owncloud.org/community/owncloud-8.2.10.zip
</url>
<web>
https://doc.owncloud.org/server/8.2/admin_manual/maintenance/upgrade.html
</web>
</owncloud>

[pmaier1]

Having got more requests regarding our misleading "stable" and "production" channels I had some discussions with @hodyroff and we want to change this according to #25633 (comment). Setting prio and triage milestone for scheduling @felixboehm.

[jnweiger]

Where shall we put a link to https://download.owncloud.org/download/repositories/10.0/owncloud/ ?
Currently stable is intentionally at 9.1.5 and production looks like a list of maintenance releases. 10.0 fits nowhere, apparently.

We may want to discourage automatic unattended online-updates for a reason, but we should make 10.0 available for fresh installs and intended updates.

[PVince81]

who can work on this ?

Ideally we need to have all channels consistent between "distro packages" and "web updater" to avoid confusions

[JKawohl]

who can work on this ?

Ideally we need to have all channels consistent between "distro packages" and "web updater" to avoid confusions

as 10.03 is approaching and we consider that "production" for the distro packages, imho we should tackle this now to avoid further confusion.

Like pmaier proposed before: we should move this to

daily
beta
fresh (formerly 'stable')
production

Here we need to work closely together with @lefherz to make sure we communicate changes thoroughly through all available channels.

[pmaier1]

@kawohl @lefherz How can we proceed here? As you correctly mentioned this topic has some kind of urgency.

Essentially we need

• an understandable write-up of the new policy as in Provide "fresh" update channel #25633 (comment)
• our DevOps team to apply these changes to the repos
• communication to the community about the upcoming changes

I really dislike the fact that current stable is still 9.1. Most community people would very probably be on 'fresh' where we could have put 10.0 since 10.0.2 while production could still be 9.1 now until 10.0.3 is released.

[VicDeo]

well, nothing but a direct approval is needed to allow 9.1.x to 10.0 update path at the stable channel.
whatever this channel is shown in admin area as stable, fresh or rotten.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

We're still talking about this: having a fresh and LTS channels.

Once official we need to make the necessary changes to the updater and any other update mechanisms.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[jnweiger]

https://owncloud.org/download/#owncloud-server-linux-packages
currently offers 10.0.4 via stable, which is a symlink to produciton. fresh is not mentioned on that website.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed.