SFML community forums

General => General discussions => Topic started by: Svenstaro on December 21, 2013, 02:32:29 pm

Title: Requesting patch release
Post by: Svenstaro on December 21, 2013, 02:32:29 pm
I'd like to request a patch release 2.1.1 since 2.2 will probably still take some time and since there have been some important fixes in git master.
Title: Re: Requesting patch release
Post by: eXpl0it3r on December 21, 2013, 02:43:57 pm
I don't see a reason for breaking the whole way SFML has been released in the past, just to get an unpolished version out. Besides that anyone can simply build from source, which is in many cases anyways the smartest choice.
Additionally soon my Nightly Builds will see their comeback.

May I ask why you'd want a "patch"?
Title: Re: Requesting patch release
Post by: Foaly on December 21, 2013, 03:38:40 pm
I don't see anything wrong with changing the release cycle. Especially since 2.2 is gonna take a while (I mean the android/ios branch just got released to the public, so there will be a lot of testing/bug fixing to be done) and the git master branch already features quiet a lot of good bug fixes (the one that I find most annoying is the window-not-getting-focused-when-clicked bug).
Of course one could compile SFML from source/use a nighly buils, but while that might be ok for developing/testing, I always ship my programs with the release version, because otherwise responding to bug becomes a nightmare, if you update the library and you start to have different version of your program out there with different version of the library.
I think that everybody would benefit from having a bug fix release soon, because it takes off some pressure and give everybody more time to test the mobile versions.
Title: Re: Requesting patch release
Post by: binary1248 on December 21, 2013, 03:54:48 pm
Title: AW: Requesting patch release
Post by: eXpl0it3r on December 21, 2013, 04:40:42 pm
Hehe binary1248 that's a good solution. :P

If you're held back by the release version, just go ahead and define your own patch version once, make backup copies in all possible cloud and non cloud storage services and use that version as your own release version. That way you still have just one version to worry about but without beeing held back. ;)

If the iOS and Android version get tested enough, then SFML 2.2 will get released faster.
Title: Re: Requesting patch release
Post by: Svenstaro on December 22, 2013, 02:59:58 am
Well, I obviously need to clarify. I'm requesting this on behalf of our users in Arch Linux, not just for one of my projects. I would not even have bothered with requesting this if it were for myself only. I package SFML in this distribution and currently there are some bugs in there that are fixed in master. However, I do not simply want to package git master and call it a day because it is not considered stable.
Title: Re: Requesting patch release
Post by: binary1248 on December 22, 2013, 03:29:55 am
Well... given the amount of users who can't resist rebuilding SFML every time Laurent pushes something, anything that completely breaks a feature will be discovered and fixed in a very short time frame. If you don't see a fix for a previous commit in 1-2 weeks it means that that commit can be considered stable. Unlike many other projects, SFML adopts a kind of "rolling release" model. The only time when the version number gets bumped is when the documentation gets changed and new pre-compiled libraries are provided on the website. Version numbers don't make any statement about stability (although Laurent probably tries to make sure they are not broken in any obvious way), and as such, I would consider any commit that doesn't completely go wrong to be as stable as a "release" with a bumped version number. There is also no concept of a feature freeze phase. New features make it in when they are "ready", and bug fixes make it in as soon as they are tested and shown to not break anything else.

Stability is always a matter of definition. Yes... there are still known bugs in SFML, but they don't (or shouldn't) cause any horrible crashes or otherwise destabilizing behaviour. Such bugs get high priority and are fixed soon after they are discovered. So like I said, if there are no outstanding "horrible" bugs, then you can consider a specific revision as stable for most intents and purposes. Most of the bugs can be worked around while they exist and comprise of corner cases most of the time. New features that get added are well tested before even seeing the light of day on GitHub anyway, so we will never get to see any unstable new features in the repository. Laurent just isn't the kind of guy who likes to share his workspace with the world :P.

For all intents and purposes, GitHub master is the stable branch.
Title: Re: Requesting patch release
Post by: Svenstaro on December 22, 2013, 03:36:49 am
Then there is also the issue that libraries that depend on SFML in the system are not guaranteed to follow master. For instance, currently in Arch, python-sfml and csfml have to be kept in sync. If changes API happen in master, they are not necessarily supported in those libraries.
Title: Re: Requesting patch release
Post by: FRex on December 22, 2013, 04:02:24 am
API changes usually mean version bump.

Quote
Yes... there are still known bugs in SFML, but they don't (or shouldn't) cause any horrible crashes or otherwise destabilizing behaviour.
Do
sf::Image img;
img.loadFromFile(".");
I dare you. :P
Admittedly it's idiotic use case and an stbi bug but still crashes. ;D Don't feel tempted to debug it though, it's been investigated already.

I'm a bit jelly of Arch now after I looked at what my yum says and: https://apps.fedoraproject.org/packages/SFML-devel :-[ ;)