@Vale-git said:
@Zireael said:
I think he is asking whether 3.1.x and 3.2 will be backwards compatible with 3.1 (note the "forwards" in OP).
That is what I meant
Ah, I totally missed that. Whoops! Sorry about that :sweat_smile:
Alas, that is not something anyone can tell with any certainty.
About this, I expect all versions between 3.0 to 3.99* have to be backward compatible. Because from my understanding only the mayor number meant compatibility break. Any software house have some rule to communicate this progress. It is possible to understand how Godot developer give these version numbers? Randomly?
I'm not 100% sure, but I think it goes like this: Major-minor-bugfix. I couldn't find the original soruce I was looking for, but GameJolt has a pretty good overview of the idea behind this versioning scheme.
This sort of versioning is fairly common and most of the repositories on Github I have seen more or less follow it. There is debate over what should be a major/minor release, but it's generally like this:
Major: Compatibility breaking changes or huge additions/changes. For example, the jump from Godot version 2.0 to 3.0 due to the 3D rendering back end being entirely redone.
Minor: New features and changes. Generally minor releases are more focused on adding just a few new features. For example, from Godot 3.0 to Godot 3.1, there are several new features (like soft physics bodies) and improvements (like the usability changes in the editor), but nothing ground breaking.
Bug fix: These releases are entirely compatible with the minor release it is under, and are only suppose to fix things. Sometimes little features and stuff creep into bug fix releases, but for the most part these only contain fixes and no new features.
Though I am not involved with the development of Godot, nor the developers that work on it. The best way to know for sure would be to ask someone like Reduz or Akien, as they probably would know.
In my point of view Back compatibility mean if i do a project in Godot 3.1 and later on will be Godot 3.2 I can load my project in the last version with no need to make any changes because if there are some new features I can still use the old ones rather to have a warning like "obsolete/deprecated" with some docs how to use the new feature.
If I understand correctly, you are talking about 'older' functions/methods being marked deprecated or removed, kinda like what Unity does from time to time?
You may need to make some minor tweaks, but from minor release to minor release, you should be able to use the same functions without needing to worry if they suddenly disappear or are deprecated. Stuff like that should only happen with major release builds, like the jump from Godot 2 to Godot 3.
However, I wrote should because sometimes things are deprecated/removed from time to time. For the most part Godot is pretty good about not removing functions/methods without ample warning, but it does rarely happen. Over the couple years I have been using Godot, I have only ran into a function/method disappearing in a future minor release once or twice, and it was easy enough to replace.
But if you are worried about functions suddenly being marked deprecated or removed suddenly, I would not worry too much. Godot is pretty stable as far as the API is concerned.
I found the transition to Godot 2 to Godot 3 not very hard and projects only needing minimal changes. I have also converted snippets of code from Godot 3 to Godot 2, and likewise it was not terribly hard.
The fact the is open source doesn't mean it have to be not built in professional way .. I'm wrong?
No, I agree. Being open source does not mean it should not be built professionally. Granted, what is deemed professional changes based on who you talk to, but that doesn't mean Godot should not try (if possible).
Hopefully this helps! My apologizes for the misunderstanding!
