App version is silently overwritten

[christianlupus]

Please provide the following details for error reports from https://apps.nextcloud.com/. Ignore in case of a feature request.

Details

Unrelated

JavaScript Console Output

None

Steps to reproduce

1. Upload an app in version A (e.g. 1.0.0) or have it in the app store (just for preparation)
2. Update the app (fix bugs) bug forget to update the appinfo.xml file
3. Sign the corrected app (version B, e.g. 1.1.0)
4. Upload the app using the web frontend
5. Get the message that the app version was successfully uploaded

Additional information

You might check that the app appears on the list of published releases. Nevertheless, the old version A was silently overwritten which might cause even more strange effects.

I would vote to

1. Include the version number in the result message on the web frontend after updating the app
2. optionally: Add a warning if you uploaded a version that was known before in the app store.

I consider this somewhere between a bug report and a feature request. I was bitten by the assumption that I cannot silently overwrite apps on the store. In that sense, it is a bug. But you can interpret it as a feature request for more output at least.

[bigcat88]

It's quite important that you raised this topic, thank you for that.
For now you're right, it's kind of a bug, but personally I think the current behavior of the AppStore is completely wrong.

I prefer the ban on overwriting application versions and correct handling of this.
For me it is a part of good software distribution practice.

Main reasons for disallowing uploading the same version twice:

Immutable Releases: Once a version is released and people start using it, changing the contents of that release could break things for the users. By disallowing re-uploads, we ensures that versions are immutable. This way, a version number is a definitive reference to a specific set of functionality and bugs.

Versioning Semantics: Semantic versioning or other versioning schemes rely on a version number to convey information about what has changed in the software. Releasing different code under the same version number would undermine this.

Audit Trail: Allowing re-uploads of the same version would make it difficult to track changes over time. This is particularly important in environments where software audits are required for compliance with regulations or company policies.

Integrity and Trust: If the same version could be changed after release, it could potentially be exploited to distribute malicious code.