0.7.0 released as stable, but nextcloud 17 is not yet released

[dvzrv]

Describe the bug
Hi! I'm packaging deck for Arch Linux' community repository.
I just realized, that version 0.7.0 of the deck app is only compatible with nextcloud 17, but that is
not yet released (in a stable version).
After updating the app and updating the server (using occ), this basically leads to an unusable application:

Set log level to debug                                                                                                                                                                            
Turned on maintenance mode                                                                                                                                                                        
Updating database schema                                                                         
Updated database                                                                                 
Disabled incompatible app: deck
[..]

This is the same problem as with the spreed app. Properly adhering to semver would clearly state, that a given release is beta/alpha or a stable release. I hereby ask you to please use proper semver for tagging new releases, as this is a well understood standard and defines clearly, what is stable and what is not. In this particular case, something like 0.7.0beta1 would have been reasonable (to later be superseeded by 0.7.0).

To workaround this issue, I will have to downgrade the package, which introduces an epoch and would have to be done on every iteration of this problem.

To Reproduce

• Install the app via Arch Linux' package manager pacman: pacman -S nextcloud-app-deck
• Upgrade the server via occ

Expected behavior
Deck 0.7.0 is still compatible to the current stable version of nextcloud (16.0.3 or 16.0.4) or a beta release is used to clearly state beta.

Client details:

• OS: Arch Linux
• Browser: all
• Version 0.7.0
• Device: server

Server details

Operating system: Arch Linux

Web server: nginx

Database: mariadb

PHP version: 7.3.8

Nextcloud version: 16.0.4

Where did you install Nextcloud from: Official Arch Linux repositories

[juliusknorr]

Deck 0.7.0 is still compatible to the current stable version of Nextcloud (16.0.3 or 16.0.4) or a beta release is used to clearly state beta.

This is unfortunately not possible due to some activity API changes in the server. 0.6 is still the current version for Nextcloud 15/16.

Apps rely on the server version, so the latest version should not always be considered to be working for every Nextcloud release:

I did not release 0.7.0 as a beta1 because on the deck side it is considered stable (as the minor version bump was mainly to differentiate between the 16 and 17 compatible releases).

For that reason you as a package maintainer need to check if a new release is actually compatible with the current release of the arch nextcloud package I'd say.

Thanks for your work on the arch maintainership, I hope that answers your questions.

[dvzrv]

I did not release 0.7.0 as a beta1 because on the deck side it is considered stable (as the minor version bump was mainly to differentiate between the 16 and 17 compatible releases).

That is exactly what this ticket is about: Using semver to ensure, that a stable version of deck doesn't match an unstable version of nextcloud (which it currently does).
The minor version bump indicates a new stable version, which should be compatible to its current stable dependency - nextcloud server.
There's nothing wrong with releasing 0.7.0 when nextcloud server 17 arrives, as it'll order before 0.7.0-beta1 in accordance with semver. This would signal to every person: This software is beta or to be used in a beta environment. Don't package!

Apps rely on the server version, so the latest version should not always be considered to be working for every Nextcloud release:

In the scope of the spreed ticket, the behavior of nextcloud was changed explicitly to allow for proper semantic versioning of the apps: nextcloud/server#14994

For that reason you as a package maintainer need to check if a new release is actually compatible with the current release of the arch nextcloud package I'd say.

You can't honestly expect every packager (I maintain more than 300 packages in my free time, others less, some far more) to constantly check a bunch of websites manually to figure out from an arbitrary release note stating "Make deck compatible to Nextcloud 17" (there's nothing written about: "now incompatible with nextcloud 16") to derive what's going on.
I would rather argue, that the developer of a software is supposed to make sure, that a stable version integrates well with the stable version of its (sole) dependency.

As a sidenote: There's no way (at least not to my knowledge) for packagers to use the inherent, metadata based logic of nextcloud server, determining which app version is allowed on which server version during packaging. Packagers have to rely on upstream to do the right thing. On Arch we're very close to upstreams' stable releases, which is why we're basically moving in the same pace as (stable) nextcloud server and its apps.

It would be very beneficial for downstreams and general visibility to adhere to semver (across apps and not just in some, e.g. spreed) and use beta/rc/alpha where applicable (especially in nextcloud server beta phases)!

[juliusknorr]

Thanks for the detailed response, I must admit, I haven't thought in depth about distribution packaging of apps.

"Make deck compatible to Nextcloud 17" (there's nothing written about: "now incompatible with nextcloud 16") to derive what's going on.

That is maybe a good point that could be added to the app developer docs, so devs become aware that there are other forms of app distrubtion than the app store, that do not include a server release compatibility check via the appinfo.xml

In the scope of the spreed ticket, the behavior of nextcloud was changed explicitly to allow for proper semantic versioning of the apps: nextcloud/server#14994

Ah nice, that wasn't on my radar. The main reason for me to release 0.7.0 now was to make it easy for beta testers to get it installed, but with the server patch, I'll try to stick to proper semver in the future with a -beta release.

[dvzrv]

@juliushaertl thanks so much for following up on this!

Yes, a common workflow would be pretty awesome. Do you know where the documentation for app developers can be discussed?