I just thought a bit more about it, we don't we create an additional "release"?
We could maybe stay with our current release cycle, but in addition to it, we could create releases for testers. They could be released every week, branching from head on monday 0:00, and feature freeze for one day, from sunday 0:00 until release which could be monday 0:00.
This way, we would create the possibility to test new features, but don't need to have them as stable as a release, as they are just wip-releases, if they compile fine and are installable and bootable, they could be releases.
This is a _bit_ like Microsofts CTPs, but they would be more often.
If you think, branching is a bit too mush work, I would suggest to create them from head, I don't think, it would be a very big problem to call for a feature freeze on head for one day in the week, and additionally this would have the advantage, that head would be more stable (it is very stable at the moment, but from time to time this chages, and this way it wouldn't).
This is just an idea, it's up to others, what they make out of it.
Greets,
David Hinz
And yes, I know this is getting a bit ot, but that's one of my hobbies, I guess...
Magnus Olsen schrieb:
We got featuere freze for 0.2.9 And if we start make one expetion then it will end up with next one. I got code I want to be in 0.2.9
About new cool featuer for directx, it is not even commit yet for I need more testing. then I commit some real cool stuff for dx, like new sync of dxdiagn with wine to was way out of sync. I want see it also in 0.2.9. And I want also see the new sync with wine in 0.2.9. I want see alex ws_32 code in 0.2.9 shall I go on.
But we got a featuer freze for 0.2.9. and it must and shall be respekted. other wise will end up with alot of new featuer in 0.2.9. I am agains adding any new featuer for 0.2.9 it will end up with a mess. and DO NOT BREAK the relase process rule. THEY must and shall follow to 100%.