If we as a project are committed to doing 0.9, 1.0+ releases it means we can't simply break code people are using to play their games for months at a time and shrug it off
After 1.0 there will be a stable and a development branch, the stable one for users, and the development one for new stuff, where it doesn't matter if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work.
Ivan.
Ivan Leo Puoti wrote:
if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work.
It's also true that the kernel is not going to branch 2.7 anytime soon.
I don't think that a breakage in d3d can be an option now. Wine is an 'old' project also if not stable or mature, and breaking stuff now is a big problem to users.
Also, as I'm not using d3d myself, if the compilation is broken, I can neither use wine for normal 2d desktop apps.
IMHO a temporary branch until completion of the new support can be a good way.
I don't think that a breakage in d3d can be an option now. Wine is an 'old' project also if not stable or mature, and breaking stuff now is a big problem to users.
Well, if that is the case, we need to recruit someone to do 'proper' releases as there are no guarantees for now of any stability between any releases (the day the config file goes into the registry or when the new window management is comitted, I think that a LOT of breakage will occur).
At least when the breakage is in the main tree, people are more motivated to fix it than when lying in a test branch that nobody will get and use :-)
Also, as I'm not using d3d myself, if the compilation is broken, I can neither use wine for normal 2d desktop apps.
Nobody ever told about any 'compilation' breakage... Any patch sent to the list will compile (modulo GL header issues :-) ).
Lionel