This might be a fairly simple example where backward compatibility can be achieved with limited efforts. But there are other areas, where this is almost impossible. Replays is one of them. The reason here is not only the code changes (which are quite large but still manageable) but also the fact that not every necessary information to do a replay is stored in the savefile. All the unit stats are missing. This is what in the end made me refuse from introducing backwards compatibility for replays. I really would like to see this because i would like to take a closer look to my 1.0 replays. But it would mean a tremendous amount of effort.
I fear that the same could happen to WML. There is some changes (like unit animation) that do not break backwards compatibility but mark certain tags as deprecated. So there might well be a incompatibility in the future. I am not saying that we should not have backwards compatibility. But if we do want it, we should make a very fast decision. Otherwise trunk with its current development speed will make that almost impossible very soon. And with such rather dramatic changes we should keep in mind that maintenance will increase more and more over time. Regards Jörg (Yogi) >David White wrote: > >This adds another question: do we want to strive for backwards >compatibility? > >That is, do we want to make it so a campaign that works for 1.0.x will >also work for 1.1.x? That way, a campaign designer could make their >campaign work with 1.0.x and they would make it supported everywhere. >The disadvantage for them would only be that they would have to forego >using features that are available in 1.1.x. The disadvantage for us as >engine designers would be that we would have the added burden of making >things backwards-compatible. > >I think the backwards compatibility is fairly important though, if we >are to really stand behind 1.0.x as the 'stable' version of Wesnoth. If >we can't show that we're willing to stick behind our stable version, >Wesnoth will become an ever-changing game that is never really stable. _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
