SFML community forums
General => SFML website => Topic started by: Tukimitzu on August 15, 2016, 06:03:18 pm
-
Hello,
I very much like the new "old version" warning on the website. It was very convenient for me while the 2.3.2 version was the most recent one. Now that it isn't, it's not that useful anymore, unless I update my library.
What if aside from linking to the most recent version, it gave you a link for each version? I don't know the complexity of such task, I'm just throwing it out there.
I'm talking first world problems here, the website is already great.
-
2.3 tutorials (http://www.sfml-dev.org/tutorials/2.3/)
2.3.2 documentation (http://www.sfml-dev.org/documentation/2.3.2/)
If you click on the website's Learn (http://www.sfml-dev.org/learn.php) section, they're all at the bottom of that resulting page.
-
What I mean is this: let's say Bob googles "sfml sprite", it will link me the sfml 2.0 (or whatever) sprite documentation. But Bob is not using the version 2.0 nor the latest one, he's using something in between. So it would be nice for Bob if the "old version" warning included links for every version so he be redirected to the version he wants.
The more I think about what I'm asking the more spoiled I think I am.
-
1. I don't think it's that hard to go back to the menu and select the version you want.
2. There's no reason to not upgrade, we ensure backward compatibility.
3. You can perfectly read the latest doc even if you use an older version, new things in the API are should be clearly marked as such.
-
@Tukimitzu, there is already a thread with a discussion about this (http://en.sfml-dev.org/forums/index.php?topic=19663.0).
2. There's no significant reason to not upgrade, we mostly ensure backward compatibility.
Fixed :p
-
Fixed :P
I guess we can find more or less valid reasons to use an old version, but backward compatibility of API is a strong requirement; if you have an example of something that was broken between minor revisions, please tell us :P
-
if you have an example of something that was broken between minor revisions, please tell us :P
2.3.2 - 2.4.0: Requirement of using setUniform instead of setParameter forcing all setParameters to be replaced to be able to use 2.4.
2.2 - 2.3: Requirement of more dependencies for building statically forcing all new dependencies to be added before the upgrade can be used.
I want to make it clear that I am not complaining; I'm simply stating some things that I have noticed. I upgrade usually as soon as I can and I am generally happy to update the code or build settings to match. My point was that it isn't always perfectly backwards compatible; some (slight) modifications are (sometimes) needed per versions.
-
2.3.2 - 2.4.0: Requirement of using setUniform instead of setParameter forcing all setParameters to be replaced to be able to use 2.4.
setParameter can still be used though, since it was deprecated, not removed.
-
setParameter can still be used though, since it was deprecated, not removed.
It can be used but - in some environments - not without modifying some settings.
-
Strictly speaking, the same code will still compile with any new minor version. The environment, or warnings that may help you get rid of deprecated calls, are not part of API compatibility.
This is slightly off-topic though, so let's focus on the subject ;) My point was that documentation for 2.4 is valid for any 2.x, to the condition that new functions and classes are clearly marked (which is not the case, apparently ;D).
-
My point was that documentation for 2.4 is valid for any 2.x, to the condition that new functions and classes are clearly marked (which is not the case, apparently ;D).
That'd be indeed something nice to have. If one has time and is motivated, I guess we only need a Doxygen macro, similar to the one for deprecation maybe, and to go through the changelog (or, better yet, diffs between git tags using git diff <V1> <V2> --ignore-space-at-eol 'include/**.hpp') to identify new features for each of the 2.x versions. If anyone is interested to do that... ;)
-
Doxygen has \since for that purpose.
-
Good, that makes it even simpler!