Publishing multiple builds targeting different nc versions

Hi guys,

I try to upload a build for nc <= 11 and one for nc 12 into the app store, but it seems that only the latest upload is used/displayed as you can see here. The one build has <nextcloud min-version="8.1" max-version="11"/> in his dependency list and the other <nextcloud min-version="12" max-version="12"/> . Any ideas or suggestions? Am I doing something wrong?

cc @LukasReschke

@BernhardPosselt any idea? The appinfo.xml seems okay.

@LukasReschke i suppose the info.xml is no issue because it validates, correct @sualko?

@sualko am I understanding your issue correctly: You are trying to upload two builds with the same version number but different code?

Yes it validates and yes you understand this correct. The nc 12 version uses a the new iconsection interface, but this is the only difference.

The app version must be unique, that’s why there’s only one app in the end because the last app overrides it. You have to use a different version for different code (which makes sense).

Why don’t you use a stable version for your old code like nextcloud does?

Why don’t you use a stable version for your old code like nextcloud does?

Because there is no feature difference between both versions and I would like to stick to the chat core lib (the chat app is just an wrapper for www.jsxc.org) version, because otherwise I think users could get confused.

According to http://semver.org adaptions to use an new api would be only a feature bump and to use therefore a stable version, which would require a major bump, is a bit over the top in my pov.

Am I the only developer with such issues? Do you have another idea to solve my issue in a user friendly way?

According to http://semver.org adaptions to use an new api would be only a feature bump and to use therefore a stable version, which would require a major bump, is a bit over the top in my pov.

Yep, but your dependency requirement on a newer Nextcloud version is a break in the backwards compat so increasing the major version is required. Semver is about breaking changes and has nothing to do with versions having the same features.

Do you have another idea to solve my issue in a user friendly way?

Nope, because it’s not semver compatible :slight_smile:

Also think about upgrading Nextcloud: the current version will not be compatible anymore and there won’t be newer versions on the app store. This would require Nextcloud to do same version equality checks as well (which is not supported atm). Also think about the user being prompted to upgrade from 3.0.2 to … 3.0.2. This will be a big wtf :slight_smile:

TL;DR: fix your versioning scheme :smiley:

your dependency requirement on a newer Nextcloud version is a break in the backwards compat

Jep, that’s right, but anyway, I didn’t change my api which is required for a major bump, as semver says:

MAJOR version when you make incompatible API changes

which Nextcloud did, but not my app. Anyway I think this discussion is unnecessary, because your latest argument is quit strong.

fix your versioning scheme

I will see what we can do… :blush:

Just fyi for API versioning: I version that one differently via a parameter in the URL.

Also bumping the major version does not mean that you broke backwards compatibility on all layers. For libs you probably only increase the major version for API breaks but thats because a lib is basically only an API :slight_smile: