Slow Red-eclipse Release Schedule (Version Releases)

[JamesClarke7283]

There has not been a tagged stable release for 2 years, 6 months, with 1130 commits to master since the v2.0.0 release.
I feel, the large lag between releases, means non-technical users(who dont know how to compile from source) won't necessarily get the best experience. I understand that stability is an issue. But typically, that's why semantic versioning exists, to make distinctions on how to deal with compatibility and general stability.

In my opinion, i would like to see 6 monthly, at least, even if minor releases. As users can benefit from stability improvements as well. For example, the Steam & Current release through github. Does not reflect the progress which has been made on this game.

As a user of this program, i typically compile from the source-code on the master branch(not stable branch), with the WANT_DISCORD, WANT_STEAM flags set to 0. As i don't use those programs(non-free software). However i feel a release schedule and milestone of some kind, would be beneficial to the users, and potentially improve adoption of this game, as i see it as a very fun and engaging game, i even compile versions for close family and friends and they like this game too(With use of a Gamepad and AntiMicroX, it plays like they are used to on consoles as well). Much respect to those working on this project (:.

I am very focused on stability as a software developer as well as a user, and in my opinion 2 years is too long especially for minor releases, and those 1130 commits, some of which are bug fixes to v2.0.0, wont reach domestic users fast enough.

Its also worth noting even on the master branch ive had good stability(not that its the case all the time, master is meant to be unstable), so i think with good use of semantic versioning and separating the breaking changes with branches,etc. Some minor appearance and usability improvements could make all the difference as well.

I am curious to see what people's thoughts are on this, and what challenges exist, what we can do to resolve them, etc.
Thanks for reading (:

[qreeves]

Users do not need to compile from source code to use the development version. You can easily switch between branches on the "Betas" tab on Steam, and for those who dislike that platform, we continuously integrate the project and upload the binaries to the deploy repository.

We'd all like to see more regular releases, but we are also not a typical open source project with a large number of contributors. There are a lot of works in progress happening that aren't suitable for end users to be exposed to as they will probably break things. In the end we're only a handful of people randomly working on things in our spare time, and large swathes of the project are solely dependent on myself. I've been at this for 15 years and don't dedicate as much time as I once did as I have other hobbies occupying my time quite often.

If you're a software developer, then you're encouraged to go through the issues and fix the outstanding bugs and requests. This will lighten our load enough to focus on polishing up the unfinished bits and get a release out sooner. At this point we're aiming for some time in this half of 2022 for a release.

[JamesClarke7283]

Thanks for your response.
Regarding the scheduling, perhaps its fine, if its easily installable on systems, without installing proprietary software.
There are 2 issues though.

Firstly, the master app images are not being built as far as I know, and if they are, the Deployment system does not appear to be working for it.

There is no AppImage built here:
https://web.archive.org/web/20220724085152/https://github.com/redeclipse/deploy/releases/tag/appimage_continuous_master

I have not been able to download the 'master', appimage, on multiple occasions. So i suspect its an issue with the build system. When ive visted there in the past, its only shown the source code, assets.

The second issue, and i am not sure if it effects the master AppImage version,

But when you build redeclipse, it builds with non-free dependencies, (discord and steam).
I don't know if its just the clients the libraries use are non-free, or the linked libraries for them are non-free as well.

I would argue that those flag's should be turned off by default. Especially in the later case, when the end user receives a AppImage with non-free binaries included.

Currently its not too difficult for people compiling from source, to disable this with the following:

sed -i 's/WANT_STEAM=1/WANT_STEAM=0/g' src/semaphore.sh
sed -i 's/WANT_DISCORD=1/WANT_DISCORD=0/g' src/semaphore.sh

This Might be especially useful for people, wanting to package RedEclipse on FSDG compliant distros, like Trisquel.

I would also like to know how to build my own AppImage of redeclipse, but that is outside the scope of, RedEclipse releases for end users.

[qreeves]

The issues with the AppImage not uploading correctly are known but the issue has not yet been tracked down properly in the build system. They are uploaded as drafts and sometimes doesn't get published by the tool being used.

Red Eclipse doesn't aim for FSDG compliance in the builds we produce. We are open source as a courtesy, not because it is a defining philosophy of the project. This equates to "free as in beer" not "free as in speech".

The majority of users aren't concerned with such things and we create releases that are the same on all supported platforms. Our primary distribution method and supporting services are provided by Steam, and Discord "now playing" integration is a method of promoting the game.

When someone creates a bundle for a distribution they almost always compile from source rather than using our binaries (to link to local libraries, etc), which is why these build flags exist. Most users who are that concerned about non-free/privacy issues typically also build from source. It should be noted that the mentioned flags are not on by default in the Makefile.

Building the AppImage yourself can be done with our builder tool: https://github.com/redeclipse/appimage-builder