Spring dev must honor backward compatibility! plsss

[msafwan]

Backward compatibility is beneficial to Spring Dev because it allow every single mod to run in all version of Spring and help debug issues.

[SpliFF]

Your patches are welcome, because, you know, nobody thought of that before.

[SinbadEV]

Once all the lobbies get streamlined multi-engine support it will be a non-issue... Game devs can just stop updating their games for new engine versions and players won't even know any better.

Pity that no-one will test new engine versions then though.

[msafwan]

Nooo!
I don't want to sound negative!
Please don't sound negative like we are in Free-market system where we can bought service with threat of no demand!!!!
Pls noooo!

What I mean is: Spring dev has put this gigantic effort in adding something new to Spring but as a side effect it (might) break compatibility.

Spring dev are really awesome people who coded all this awesome stuff complicated simulation machine (there is no one else to depend to help with Spring stuff but them!!) but it just that they might not see backward compatibility as something big? (I don't know!)

I just want to voice out this opinion (this opinion only) that:

backward compatibility can be something big too! If Spring dev has to choose between consistent argument/callin name/output & backward compatibility, pls choose backward compatibility first and change wiki/documentation instead.

[smoth]

What in particular are you crying about?

Some things get broken report these on mantis. If a project falls behind and is no longer playable, that project is dead anyway.

[msafwan]

It sounds like purposely making something else to die out.

Its like preventing people from relying on old system as a stable/reference base from which they can move on to develop new feature.

I don't like the idea that once a dev retire the whole system is dead.

There is no more space battle mod, no more fighter plane mod, because they are all dead!

[smoth]

Too bad.

Things change adjustments get made, often updating a project to work in the new engine version is easy. However, you don't want to make that effort.

Again what is the particular issue or are you just whining out of ignoramce?

[knorke]

Things change adjustments get made, often updating a project to work in the new engine version is easy. However, you don't want to make that effort.

http://code.google.com/p/zero-k/source/detail?r=9831
http://code.google.com/p/zero-k/source/detail?r=9530
acuelly he did and noticed it is unfun which is true.

The problem is that not every change can mod-side be made backwards compatible. So people might know how to adapt their mod to a change but do not do it because they still want to dev/play with current engine version. Having two mod versions is considered too much hassle, so mod is not updated and new engine version not tested.
With SVN maybe mod devs can create a fork "fixes for upcoming engine version" and then commit fixes there without breaking "currently played mod version"? When engine is released, merge the forks. But is more complicated of course and you might still need two mod versions on your computer etc...

[smoth]

I didn't say it is fun.

Or he could make a mutator, that way he has a working version with his changes ready for when the next release is dropped.

[gajop]

Do you really think that any dev (here) gets it off by breaking backward compatibility?
It would be too much work to maintain it forever, it's not worth it.

[Silentwings]

Imo its good in the long run that mods are forced to keep up with new engine versions, because then mods that are currently played are ones with active devs, which in turn tests the current engine and makes the engine improve. Of course when backwards compatability is possible without huge amounts of effort its worth it but my feeling is that we all know this and its already what happens.

If the mods/maps that end up being played are not kept up with engine versions at some point it reduces motivation to develop engine/mods/maps/etc for Spring in general, which imo is clearly bad.

[Neddie]

In open source, as in business, you are often faced with the choice between advancement and support. The longer you delay advancement in favour of support, the harder it becomes to achieve the former and the more painful your eventual transition from the latter becomes.

In many cases it is better for the module to adapt to the engine, than the engine to remain hamstrung by the module.

[msafwan]

Nooo,

What I meant is really simple thing like NOT to change the ordering of argument for existing callins.
- If you change a,b,c to a,d,b,c then then ALL gadget/widget must change (but if you don't then nothing happen)!

Or changing the type of output from a callout.
- If you change 1 and 0 to Boolean then ALL gadget/widget must change (but if you don't then nothing happen)!

Please don't even think about "how to geo-engineer the open source society by keeping old mod to die out using simple but subtle changes" or "mod must die or Spring won't success in future arena!", what matter is this simple:

whether Spring dev choose not to change those simple thing or change those thing and kill a non-maintained mod.

[smoth]

I think you are wildly exagerating things and see your arguement as foolish. Spring should not be held back for the sake of a dead project. In the the YEARS that I hsve done spring content dev wotk the only real killer was pathing related. Something that was and is still improving.

[zwzsg]

If a project falls behind and is no longer playable, that project is dead anyway.

I cry about that.

[knorke]

In the the YEARS that I hsve done spring content dev wotk the only real killer was pathing related.

Oo
The "removal of .n entry in array tables" required updating of all games, including yours, or they became unplayable. (at very least some "default" widgets like healthbars broke)
"What engine change has broken game play!?!" appearently is a common thought, for you too: http://springrts.com/phpbb/viewtopic.ph ... 2&p=493107
You even made similiar thread as this one about engine changes breaking games: http://springrts.com/phpbb/viewtopic.php?f=12&t=23913

If Spring dev has to choose between consistent argument/callin name/output & backward compatibility, pls choose backward compatibility first and change wiki/documentation instead.

Consistency is important too, especially for potential new game developers. If they see 0/1 and false/true are used randomly and sometimes numbering starts from 0, sometimes from 1: That can scare people off. Spring had many such slightly strange things things were "fixing" initially caused drama but in the end was for the better.
So these changes seem silly but I guess that is the idea behind it..

This is still true of course:

If a project falls behind and is no longer playable, that project is dead anyway.

I cry about that.

At least they die for science and progress, which totally makes a difference for the heaven and hell thing.

[msafwan]

IMO its more fun if Spring dev simply document all tiny nuance here: http://springrts.com/wiki/Lua_Scripting
Its better to make some sensible comment there rather than making a code change that kill a Mod.

I would get confused too if the stuff is not consistent but if the documentation is right, then I could always refer to it I think.

It would be cool if I could play all those old Mod. I'm actually new here, I am not around coding stuff when all this "n" issue is around. So in my perspective I could tolerate inconsistent interface as long as I can read them in manual... but I CANNOT live with this maintenance hell...

[SpliFF]

You have options that are more effective than complaining. One of those is to stick with an engine version you are happy with and distribute it as a portable (standalone) install. You would need to run your own server and autohosts though. A better option would be to help with testing multi-engine support in lobbies. That is something productive you could be doing right now.

[PicassoCT]

In open source, as in business, you are often faced with the choice between advancement and support. The longer you delay advancement in favour of support, the harder it becomes to achieve the former and the more painful your eventual transition from the latter becomes.

In many cases it is better for the module to adapt to the engine, than the engine to remain hamstrung by the module.

You can however advance and still be compatible to your ancestors..
x86
However, every wrong design decision will hunt you. And should your audiences behaviour change, all the backwards compahillbillity wont save you.
arm

[FLOZi]

In the the YEARS that I hsve done spring content dev wotk the only real killer was pathing related.

Oo
The "removal of .n entry in array tables" required updating of all games, including yours, or they became unplayable. (at very least some "default" widgets like healthbars broke)

Even the .n change was ~5min with n++ or grep to fix in large established projects.

The importance of changes that break BC will always be debated but in the long term most are done for reasons of consistency and/or required changes for some new feature which have long term benefits far in excess of the short term inconvenience.

For those who decry the death of minor projects... resuscitate them. You (knorke and zwzsg) are far more capable of it than most.