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
.
For all intents and purposes,
GitHub master is the stable branch.
