Deprecating option flags should be done gradually, not changing for each version.

[Midou36O]

Most projects often change features by deprecating them first, and redirecting to the main feature, and add warning for a certain period of time before changing them, beans does not do that, i have witnessed 2 server hosters struggling to know what's happening when versions change and it's getting frustrating to deal with this, suggestion to solve this or at least inform would be the following:

1. Add the new function that is supposed to replace the old function
2. Add a warning to the old function, saying it is deprecated, and the new function should be used instead
3. After a certain period of time (weeks, months), the warning becomes an error, and tells you to use the new function instead.
4. Remove the old function

Doing this ensures the user knows what is happening and is not confused as to why this feature "disappeared". Thanks.

Example of how PostgreSQL deprecates features
Example of what mariadb thinks of deprecating features

[ktwrd]

Hi Midou,

1. I'm well aware what semantic versioning is, and how to properly phase (or replace) out features. I would prefer that you didn't assume that I have lackluster knowledge about software development.
2. Server Owners and end-users can read the changelog (which is on every release, and in the #updates channel in the Open Fortress server) so they know what has changed or has been fixed in the version that they are using.

When I mentioned the --no-pause argument being renamed to --headless, that is something that would occur in PR #6, since the literal definition of it would've changed. That PR may never get merged since Adastral could become stable before then and the focus would be on the CLI portion of beans-rs only (or a CLI for Adastral). Since changing the name for that argument is a minor change, it would be applicable for v1.5.0.

There was always intention to add some sort of message/notification to phase out the --no-pause argument with --headless (once again, if #6 gets merged), which I did not communicate in the Open Fortress server since I was on my phone. This is something that has already been implemented for the AppVar feature in beans-rs, since a method in that module is being phased out. (this commit, in the parse function).

[Midou36O]

First off, sorry for making it sound like you lacked the knowledge about software development, I checked the versionning of the releases and they seem to be properly done. However, I wonder if there is a way to make an old version supported for a little longer by providing security patches (by cherry picking the commits that are relevantto security) while keeping the features the same. Maybe that would be too much effort since extended support often means the users do have to pay because they were too lazy to get up to date with their infreastuctures. But aside from that, for answer 2 a new release should normally inform you at least once of the changes if they're breaking ones.

Oh also, sorry if it may have come rude since the last time we talked, It's already great that a unpaid community project is working well compared to many FOSS projects who work half the times or don't at all :)

[ktwrd]

However, I wonder if there is a way to make an old version supported for a little longer by providing security patches (by cherry picking the commits that are relevantto security) while keeping the features the same.

With cherrypicking security fixes for older versions, that is something that can be done, and will be considered for future releases of beans-rs (incl endpoint changes, like for sentry or the versions.json endpoint).

It's already great that a unpaid community project is working well compared to many FOSS projects who work half the times or don't at all :)

I'm glad that you view beans-rs that way, and I hope that I'll be able to keep that view for adastral-cli (when Adastral goes stable, since it uses a different versioning system). I've put a lot of effort into maintaining beans-rs and there will always be some sort of support for this, but I have mentioned in the #updates channel in the Open Fortress server that I have dropped support for specific versions because they have incomplete or completely broken features, or it's borderline impossible to debug for end users.

Some examples of that are

• < 1.4 since the update subcommand is completely broken
• 1.4 - 1.4.3 since error messages are incomplete
• < 1.4.5 since gameinfo.txt backup/restore is broken, and won't work if your gameinfo.txt is broken.