Promote SFML 2 instead of SFML 1.6

[Nexus]

Hi,

Almost every newcomer begins to use SFML 1.6, because it is declared as "current version" on the website, and they get the impression that SFML 2 is unfinished or beta, although much more mature than 1.6. Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead. I actually agree with him, and also often advise people to switch.

The website should really be changed accordingly. I know you will do it anyway when SFML 2 is released, but since we don't know exactly when this is going to happen, it may be better to promote SFML 2 RC already. We also avoid that people who begin now with SFML have to port everything as soon as they have learned the basics.

I am also aware that SFML 2 RC isn't complete regarding the tutorials, yet this should be outweighed by SFML 2's advantages. Using the SFML 2 doc, examples and 1.6 tutorials, most parts can still be learned reasonably. Otherwise, there is still the forum to ask.

[FRex]

+1 to this, I'm really tired of idiots who have problems writing a hello world in whatever library for graphics and at the same time say to people with couple thousands of posts that they're wrong.
http://en.sfml-dev.org/forums/index.php?topic=9720.msg66733#msg66733
This question was actually caused by the fact I was arguing with some complete moron who said that 1.6 is much betterthan 2.0(he made it sound like if 2.0 is crashing randomly) because 'Laurent said so but I forgot where and when' few months back so I wanted a post with Laurent's answer to use whenever I ran into another one of these morons.

[Foaly]

+1! Even though SFML 2.0 is not released yet, it beats SFML 1.6 by far. If you're about to start coding with SFML there is absolutely no reason to use 1.6

[Tank]

I second what Nexus said. There's no reason to declare 1.6 being stable anymore – because it isn't. I'm aware that there are already API changes from 2.0 RC to HEAD, but that's not a problem of the "RC", it's a problem of the versioning.

Personally I hadn't release an RC, but 2.0 instead. It's much easier to throw changes into a specific version, and if users decide to upgrade, they know that they might run into compatibility issues. That way you could have just released 2.0, and some more API changes/features in 2.1, and so on.

I'd generally suggest to lower the release cycle time. It reduces the workload per version (less features added), including writing documentation. The current situation is not really feasible for development: We have 1.6, greatly outdated (for several years) and SFML 2.0 RC, which is not declared as being stable. As a new user, to be honest, I'd go with 1.6 too, just because it's "stable".

[eXpl0it3r]

Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead.

+1

+1!

I second what Nexus said. There's no reason to declare 1.6 being stable anymore – because it isn't.

I've nothing more to add other than: I strongly advise you against the use of SFML 1.6, because it's around 2.5 years old, has quite a few ugly bugs and lacks a lot of nice features (e.g. sf::VertexArray, sf::RenderTexture, ...)...

[cooldog99]

For what it's worth, I also second this.
+1!

[Nexus]

Personally I hadn't release an RC, but 2.0 instead.

I think Laurent intends not to break the API once SFML 2.0 is released. The RC says: The final version will be very similar, but there might be minor changes.

I'd generally suggest to lower the release cycle time. It reduces the workload per version (less features added), including writing documentation. The current situation is not really feasible for development: We have 1.6, greatly outdated (for several years) and SFML 2.0 RC, which is not declared as being stable.

I totally agree.

[Tank]

I seem to be one of the few people who don't have problems with API changes at all. I even think they are required if you want to keep your code clean.

I see it like this: When I'm using 2.0, and 2.1 introduces the "ThreeDeeMagic" feature which I'd like to use, then I have to adjust my code to do so. When I'm using something that's already available in 2.0 and is changed in 2.1 (API), then I need to adjust my code – otherwise I probably don't *need* 2.1. Looks quite similar to me.

Of course it's always nice to be able to upgrade to a newer version without any extra work. But if there are good reasons (more stable API, features, code design, ...), I'm perfectly fine with compiler errors after trying to upgrade without adjusting my code at all.

[Nexus]

But if there are good reasons (more stable API, features, code design, ...), I'm perfectly fine with compiler errors after trying to upgrade without adjusting my code at all.

The really annoying changes are those who let old code compile and introduce silent bugs. The change from float seconds to sf::Uint32 milliseconds was such an example, the sf::Rect modification another one (when using the constructor). I remember fixing loads of bugs because of it in Zloxx II

I still agree with you, as long as the changes are justified because of a better design or new feature, I can mostly accept them. Backward compatibility is a good thing on one side, but on the other it sometimes blocks progress and makes things terribly ugly. But we also have to consider that SFML is being more and more widely used, and some people (or even small companies) consider a stable API across multiple minor versions crucial. As the maintainer of two big projects, you probably aren't unhappy about fewer changes, either

[binary1248]

Guys like eXpl0it3r have to argument in every second post why SFML 2 is better and should be used instead.

Or he could just point at the (incomplete) FAQ which manages to get the point over somehow instead of writing the same semi-wall-of-text in every second thread .

I'd generally suggest to lower the release cycle time. It reduces the workload per version (less features added), including writing documentation. The current situation is not really feasible for development: We have 1.6, greatly outdated (for several years) and SFML 2.0 RC, which is not declared as being stable. As a new user, to be honest, I'd go with 1.6 too, just because it's "stable".

+1337
Look at the new versioning method of SFGUI (Tank's idea btw) it shows people that progress is being made but it doesn't promise them crap regarding stability . Holding up a complete rewrite in 1 version number over the course of years isn't a good idea. If you had a truck-load of coffee and could do it in a night, maybe you should go for it. But stopping support for a "stable" version for so long to work on something that you brand as unstable doesn't leave many people much choice but to use the "stable" version (which ironically is less stable than the unstable one) because they don't understand what benefits using 2.0 bring.

Actually if you consider the word "stable" implying that software is actively maintained, improved, bugs squished, etc. then you wouldn't be allowed to call 1.6 stable any more because let's face it, it's less stable than something I write for SFGUI in less than a day if you consider that it doesn't run on many very popular GPUs, crashes in way too many scenarios, etc.

Development does not always imply instability, especially not if it is on a feature by feature basis and certain features can be considered "done" independently of the others. This is what minor version numbers are for IMHO.

P.S.

and 2.1 introduces the "ThreeDeeMagic" feature which I'd like to use

What? Why didn't you tell me you wanted 3D magic? I will see what I can do. Not signing any contracts though

[masskiller]

Or he could just point at the (incomplete) FAQ which manages to get the point over somehow instead of writing the same semi-wall-of-text in every second thread .

That will only save a little typing. It has become too much of a common thing for help requests to come only to show people that they should change to 2.0 due to the fact that reporting a bug is useless for that version and that most decent help (if not all) you can get in these forums is related to 2.0 and not 1.6 since it's the most used by any user from intermediate to advanced unless there is a strict reason. The change should be done, even if the final version of 2.0 doesn't come anytime soon.

[Laurent]

Promote SFML 2
I know... but not doing it forces me to work hard on the final release (which is really close)

Short release cycles
Definitely! You can expect SFML 2.1 to be released a few months after 2.0, and so on.

Release SFML 2 sooner
A lot of stuff had to be rewritten (internal code, public API, tutorials, documentation, website, ...) and I really wanted a clean and stable base for this new 2.x branch. I want to stop breaking API compatibility with minor releases, so that SFML, with its 2nd edition, can finally be used as a stable library rather than something "unfinished".

[Tank]

What? Why didn't you tell me you wanted 3D magic? I will see what I can do. Not signing any contracts though

I want all kind of magic!

Definitely! You can expect SFML 2.1 to be released a few months after 2.0, and so on.

Please don't forget about the revision part of a version. Fixed Bug > Feature.

The change from float seconds to sf::Uint32 milliseconds

Didn't your compiler warn you?

But we also have to consider that SFML is being more and more widely used, and some people (or even small companies) consider a stable API across multiple minor versions crucial.

Yes, and an API that doesn't change means 1) it's really good or 2) the developer is too afraid changing it. I think as long as upcoming changes are communicated good enough, one shouldn't stop implementing them.

As the maintainer of two big projects, you probably aren't unhappy about fewer changes, either

Actually I really don't care that much. I add, change and remove code all the time anyway. And I guess we're not talking about changes that require rewrites of bigger parts in a project (the changes from 1.6->2.0 are massive, and big 1.6 projects might need a fair amount of time and effort to be ported; however, this is a major version change). If new versions are published in shorter intervals, then there's probably no need to increment the major version counter.

I guess we kinda agree to each other except on details. For SFGUI it would be nice to see the light of SFML 2.0, as it means one less dependency to be tracked for changes.

[NPS]

One huge argument against. I don't know about the documentation but the tutorials are only like started and they miss much (most?) of the functionalities. And that's unacceptable - reading tutorials for previous version, then looking in the documentation of both the current and the previous versions in search of changes, and finally posting on forums when one gets lost in all this IS NOT THE WAY TO GO. And that's what someone's suggesting. I love SFML not only because it works and does all the stuff I need but also because learning it is so fast, intuitive and simple! But that's not the case with the 2.0 version right now and until it is - don't promote 2.0.

[masskiller]

One huge argument against. I don't know about the documentation but the tutorials are only like started and they miss much (most?) of the functionalities. And that's unacceptable - reading tutorials for previous version, then looking in the documentation of both the current and the previous versions in search of changes, and finally posting on forums when one gets lost in all this IS NOT THE WAY TO GO. And that's what someone's suggesting. I love SFML not only because it works and does all the stuff I need but also because learning it is so fast, intuitive and simple! But that's not the case with the 2.0 version right now and until it is - don't promote 2.0.

You can skip the step of looking at the 1.6 doc, when I started I found it useless and still learned how to use the library without much hassle, porting the code between versions isn't hard and unless you want to go and use low level API right away you won't really suffer.

The Graphics API was rewritten (and for the greater good) and that's granted, however other than the adding of sf::Texture and the need to keep it alive you won't really notice the other changes unless you start using the new features right away.

I know... but not doing it forces me to work hard on the final release (which is really close)

This I would consider the main reason not to, if it means getting the final version sooner then I don't care about posting the same thing over and over in the help forums for a few months.