Request to not delete old releases

[theofficialgman]

Both 2.1.2 and 2.1.1 releases were deleted on separate occasions. Is there a reason this is being done? This breaks our scripts at pi-apps which rely on old versions staying available until our updater CI comes along and checks all of our 200+ supported apps for upstream updates weekly

[00-Evan]

Whenever I release a new patch I do so by editing the current release, changing the tag and replacing the assets. I clear out all but the latest patch for a particular release to reduce clutter, otherwise there would be a history of hundreds of redundant and often buggy versions of the game.

[theofficialgman]

I'd prefer you not do that. As explained this breaks any links to the specific version of the release that you made. It also makes the release date incorrect and I and other users can't tell that you even made a new release (it shows the date as a month ago when you actually added new assets 3 days ago). Your method is highly non-standard.

For the benefit of all users please stop doing this.

[00-Evan]

'all users'? As far as I can tell your concern relates to an unofficial distribution of the game for people using raspberry pis. That limits the number of impacted people quite a bit. The vast majority of users aren't even aware that this github page exists, and the vast majority of users who do use open-source builds depend on the in-game update checker.

Editing the release to preserve the initial date is actually intentional, I'd prefer for the date to tie into when the content in an update was actually released, not little followup patches that tweak balance or fix bugs. v2.1.3, which adds a bit of tester content, is a pretty rare exception to this.

I don't generally make changes to support unofficial distributions of the game, but I appreciate that regularly outright breaking your platform's release of Shattered isn't great. Is there any way to make the script that pi-apps has for Shattered a bit more flexible? For instance, would it be able to grab old patches if I leave them available temporarily as assets appended to the latest release (e.g. v2.1.3/...v2.1.2-Java.jar).

[theofficialgman]

'all users'? As far as I can tell your concern relates to an unofficial distribution of the game for people using raspberry pis. That limits the number of impacted people quite a bit.

Linux debian/Ubuntu based systems in general (raspberry pis, Nvidia Jetsons, orange pis, rockchip systems, apple silicon, etc). We have over 100,000 active users that use the software store. ~2000 of those users have this game installed.

The vast majority of users aren't even aware that this github page exists, and the vast majority of users who do use open-source builds depend on the in-game update checker.
Editing the release to preserve the initial date is actually intentional, I'd prefer for the date to tie into when the content in an update was actually released, not little followup patches that tweak balance or fix bugs. v2.1.3, which adds a bit of tester content, is a pretty rare exception to this.

This is disingenuous and not how any other project that uses GitHub releases works. Anyone familiar with releases would expect the date to be the date of the artifacts release. Your bugfix and balance patch builds did not come out a month ago so you should not say they do. If you keep all releases then the date will be tied to when the build is released. Each one will have the correct date and everyone wins.

In addition, if I use the GitHub watch notification system I do NOT get notified when you edit a tag in the manner that you do. I am not made aware that you made a new release and neither are any of the other watchers. I watch many repos for new releases and only have to check my GitHub notifications/email to keep up with projects. Meanwhile for this project I have to go to your GitHub page, go to the latest release, try to remember what the last version number was, and then compare it to what the version currently is. Very time consuming.

I don't generally make changes to support unofficial distributions of the game, but I appreciate that regularly outright breaking your platform's release of Shattered isn't great. Is there any way to make the script that pi-apps has for Shattered a bit more flexible? For instance, would it be able to grab old patches if I leave them available temporarily as assets appended to the latest release (e.g. v2.1.3/...v2.1.2-Java.jar).

No not really. When you change the tag you also change the base URL. I would have to query the GitHub API, filter by the major plus minor version number, and then get the corresponding URL that matches the version in the local script. All to just download the release jar.
It would be better and more standard to keep all releases like any other project does. How are users supposed to report regressions or issue comparing one point release to another when you delete the release tag and builds (some of our users have already reported issue at your GitHub, helping improve your game)?

[00-Evan]

You make some good points about new releases vs. edits that I was not aware of previously (things like new release notifications). I am still not interested in keeping outdated patches, but I will use a new release in future instead of editing existing ones for patches. This, conveniently, also means that old patches can be kept around for a little while before being disposed of.

[00-Evan]

v2.1.4 will release shortly, which will use a new release. v2.1.3's release will stick around for at least a week.