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%.