Author Topic: Feature End-Of-Life Cycle  (Read 573 times)

0 Members and 1 Guest are viewing this topic.

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Feature End-Of-Life Cycle
This is a discussion that we've been tossing around on discord off and on, this forum post serves as something a bit easier to keep track of.

Essentially, the SCP doesn't have a path to outright removal of features, only deprecation. To clarify:

  • Remove:  Completely wipe the existence of a feature from the codebase, making any of its former triggers and methods to use it flagged as an error
  • Deprecate:  Feature still works, but it won't be upgraded anymore and you may get scolded for using it.

Vanilla features will only ever be deprecated, for the simple fact that we must uphold the Golden Rule of "Thou Shall Not Break Retail," however, any and all features added to the engine by the FSO-SCP is subject to removal.  Of course, whats holding us back from doing so is that it'll break any and all mod that uses them (a Bad Thing).

However, if all we ever do is deprecate features and not be allowed to remove ones (especially ones that have their functionality merged, superseded, or outmoded by another feature) we wind up with a ton of crusty code sitting around, getting in the way of maintenance and new work.

We have deprecated sexp's, but to my knowledge we don't have a proper End-of-life cycle for features in general.  To start off the discussion, I suggest the following End-of-Life cycle:

  • Deprecate a feature for some agreed upon time, such as two release cycles (half a year) or four release cycles (a full year)
  • Once the time period is up, remove the feature.  Trying to activate the feature through whatever mechanism it uses should return an error message stating when the feature was removed.
    • Depending on the type and severity of the feature, this error message may or may not be blocking further execution of the game.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 

Offline Novachen

  • 29
  • The one and only capella supernova
    • Twitter
Re: Feature End-Of-Life Cycle
Well... as my knowledge goes, most of the older Mods that were designed for 3.6.9 etc. are not working properly with current Builds anyway and need to be updated to be work again.

And i have to say, that i encountered some slightly changed behaviours in the retail campaign missions of FS2 with a more current Open Setup. But some of them could simple be caused by the MediaVP models of course.


I do not like to drag code with me that inflates everything. Mods that require a specific build can still be played if you use the recommend build and MediaVPs from the release thread. It is not like old versions are erased from existence.
Female FreeSpace 2 pilot since 1999.
Former Global moderator in the German FreeSpace Galaxy Forum.
Developer of NTP - A Multi-Language Translation Library Interface, which allows to play FreeSpace in YOUR Language.

Is one of my releases broken or not working? Please send a PM here, on Discord at Novachen#2334 or on Twitter @NovachenFS2, a public tweet or write a reply in my own release threads here on HLP, because these are the only threads i am still participating in.

 
Re: Feature End-Of-Life Cycle
For context, how many cases would be actually in question? Is this something that would happen on a frequent basis or just every once in a while? The best reference I get for this is the Lua code which has caused scripts to break on a frequent basis.

 

Offline z64555

  • 210
  • Self-proclaimed controls expert
    • Minecraft
    • Steam
Re: Feature End-Of-Life Cycle
For context, how many cases would be actually in question? Is this something that would happen on a frequent basis or just every once in a while? The best reference I get for this is the Lua code which has caused scripts to break on a frequent basis.

I can't say for certain what the number of dead features are in the codebase currently, but I can say for certain the the end-of-life cycle should be a rare item.  Our primary course of action thus far is to add in new features or enhance existing ones, when ever possible.
Secure the Source, Contain the Code, Protect the Project
chief1983

------------
funtapaz: Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Juche.
z64555: s/J/Do
BotenAlfred: <funtapaz> Hunchon University biologists prove mankind is evolving to new, higher form of life, known as Homopithecus Douche.

 
Re: Feature End-Of-Life Cycle
For context, how many cases would be actually in question? Is this something that would happen on a frequent basis or just every once in a while? The best reference I get for this is the Lua code which has caused scripts to break on a frequent basis.
It would not be common but there are a number of features that are simply too specific and shouldn't have been done in-engine (looking at you, autopilot), ones that work but in a buggy way, or features that would be maintained but the way were defined in tables ended up being very clunky and unintuitive, and should be redone in a non-backwards compatible way. These are the main situations I would imagine for this sort of thing.

I would be overjoyed if people were OK with this, but I've generally been of the opinion that most modders would be strongly against this so I'd love to know people's thoughts.

 

Offline EatThePath

  • 27
  • Laser Lich
    • Twitter
Re: Feature End-Of-Life Cycle
As a modder I would be okay with this so long as a very clear, prominent, and explicit changelog with transition instructions was provided. For instance if autopilot was removed with the intention that it be replaced with a script, ideally I'd have that change happen hand in hand with making available the script that replaces it. Maybe not a drop-in replacement but at the very least the skeleton of it. Or if a table value is redefined in a new way (spawn weapon configuration I'm looking at you), instructions for how to produce equivalent effects in the new system.

With the way that people mod there would probably have to be a list of those for current nightlies rather than waiting for a stable to be built.
Name your damn turrets and sounds! Numbers alone aren't helpful!
"if disco is dead then I am the laser lich"
"...[Warmachine] keeps changing as fast as EatThePath can force the engine to do his dark bidding..."

 
Re: Feature End-Of-Life Cycle
As a modder I would be okay with this so long as a very clear, prominent, and explicit changelog with transition instructions was provided.

...

With the way that people mod there would probably have to be a list of those for current nightlies rather than waiting for a stable to be built.
Sounds pretty good to me. I guess there's no point in maintaining dead-ends; but I think it'd be useful to know what is being removed, ideally before a final decision is made.

For documentation there'd be a single pinned post/wiki article so you could just scroll to the version where xyz was removed.

Quote
For instance if autopilot was removed with the intention that it be replaced with a script, ideally I'd have that change happen hand in hand with making available the script that replaces it. Maybe not a drop-in replacement but at the very least the skeleton of it. Or if a table value is redefined in a new way (spawn weapon configuration I'm looking at you), instructions for how to produce equivalent effects in the new system.

While that would be the best solution idk how realistic that is.