Best ways to handle the migration of old releases in the appstore

I have an app in the appstore since all the way back in 2018. There are more than 100 releases over the years, all of which have been uploaded automatically by the build system. For a long time the pipeline simply pushed a link to the artifact from the job to the appstore. It’s simple and it worked but the obvious downside is that now i can’t delete any of the many gigabytes of build artifacts that have accumulated over the years.

A few years back i changed the pipeline to push a package to Gitlab Repository and publish the package from there. That solved this issue for new releases.

But now i still have 5+ years worth of old releases that still link to random artifacts on my Gitlab instance.

From what i know about the Appstore i can’t update an existing release. So my idea would be to download all the old releases and push them into the Gitlab registry. Then i would delete the releases from the appstore and publish them again, now with the updated url pointing to the package registry.

My concern is that these are old releases limited to Nextcloud versions that are long out of support. Maybe the appstore might reject them due to that? Or maybe it won’t allow me to upload releases whose versions are way lower than the newest one?

Has anyone ever done something like this? Or maybe other insights into the issues i could run into?

And for anyone wondering why i bother with migrating instead of just deleting them: The oldest server still reporting usage is NC 15, which was the first version to even have the opt-in weekly usage report in the app. I don’t want to brick the upgrade path for these servers.

I have not previously done the EXACT thing you have described, but I have previously updated the URL of an existing release. That was because I had a typo in the git tag name/URL, but that was for the newest release. Just changing the URL and re-“uploading” to the app store with the new URL worked flawlessly, it overwrote the old upload cleanly with no weird duplicate versions or anything like that.
So yes, you can update existing releases, but I have only tested it personally with the newest release.
To find out if there might be problems re-uploading OLD versions I dug into the appstore code:

Here is the code for the version upload endpoint: appstore/nextcloudappstore/api/v1/views.py at 7629fea1cd2f2fe7599029015843b3a781b7e29e · nextcloud/appstore · GitHub
There is no such check in that function or in the AppImporter class it uses.
Should not be an issue.

If you are concerned about the old releases overwriting the description of you app, I checked that too, that is not an issue, the app properties are only updated for non-nightly, non-alpha/beta (= “-” in version number) versions, that are the newest or only release of an app.

There is no such check in the above mentioned function either.
And from an operational standpoint it is unlikely that the minimum allowed version would be hardcoded, it would probably be a config value the app store admin sets and I checked the config code and there is no such setting.
(The app store does have the concept of a Nextcloud core release being supported/unsupported from the syncnextcloudreleases command --oldest-supported arg, but that is just for the /api/v1/platforms.json endpoint and not checked for app uploads)

So I think the way to move the old artifacts is:

  • Download from old host
  • Upload to new host
  • Keep releases in app store, no need to delete them
  • Use the usual app update upload form to submit the new URLs for the old versions

Seems pretty straightforward, granted, I did not test this, but most of my apps are for work, so I certainly won’t test on them ^^

P.S.: Running an 8 year old version is insane, I would not bet on that instance ever getting updated or its owner still being alive ^^

Wow thank you a lot for your answer and the research you did for this. I didn’t even consider that the appstore source code may be public :smiley:

This definitely makes that migration a whole lot easier.