:> In otherwords, we should branch with the 4.1 release rather then the
:> 4.0 release.
:
:Sounds a lot like 3.x to me. We didn't branch at 3.0 either, we
:branched one release afterwards and only after people threatened to
:mutiny if we didn't since the usual pattern up to that point had been
:to branch immmediate at the dot-zero. It didn't seem to help, as your
:own complaints would indicate.
:
:- Jordan
Wait until 4.2? I don't know the answer, Jordan, but I am reasonably
confident that an official stabiliziation period of a few months will
help a lot. The circumstances of the 2.2.x -> 3.0 release (the 18
months you quoted) were special and should never be repeated, but I
think it is precisely the fact that 2.2.x went on for so long that wound
up causing people to give up and start working on new stuff prior to
3.0. This made 3.0 especially unstable.
So going to the 12 month schedule is a wonderful idea, but doesn't
quite get there in my book. There is no significant feature freeze
prior to a .0 release which almost guarentees an unstable release.
That's ok since we tell people that .0 is never stable. But .1 has
to be stable and the only time we have to do it is between .0 and .1.
If we enforce a stabilizing period between .0 and .1 and branch at .1
rather then at .0, this combined with the 12 month schedule should result
in pretty damn good releases.
If we just do the 12 month schedule, I don't think it will produce as
good a result.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
