3.0.3 and 3.2 releasing

Antonio Huete Jimenez ahuete.devel at gmail.com
Fri Aug 24 10:24:14 PDT 2012

Hi all,

I think following up minor-releases is a good thing for many reasons
that have been already exposed. There should not be "showstoppers" in
my opinion; they should be measured by the amount/weight of the fixes
MFC'ed instead. For example, if the wire_count bug is still being
fixed we roll 3.0.3 even if it isn't fixed and then we roll 3.0.4 or
even 3.0.99 if needed. Minor releases are just steps forward to
stabilise what's already delivered.

Also I would like point out that another good reason to do a close
follow up to our stable release is the fact that we remove old or
unused parts of the OS that we consider obsolete but that others might
still use. So I think the better follow-up we do to our stable
branches and minor releases, the better old releases will remain.

My 1,99 cents.

Antonio Huete

2012/8/24 Justin Sherrill <justin at shiningsilence.com>:
> The 3.0.3 tag was done to get the existing fixes out there.  I'm sure there
> will be more bug fixing, but that will continue in some capacity all the way
> to the 3.2 release.  Or at least I hope it will!
> Anyway, if there are more bugfixes that need to get out there before the
> release, 3.0.4 can be tagged.
> On Aug 24, 2012 10:07 AM, "John Marino" <dragonflybsd at marino.st> wrote:
>> On 8/24/2012 15:50, Sascha Wildner wrote:
>>> Can we please leave this "show stopping" to our major releases instead
>>> of bickering over the minor ones?
>>> That said, I do understand your general point, of course. I just
>>> disagree that it applies to minor releases, too. Maybe we should stop
>>> calling it "releasing". How about "updating the release ISO with some
>>> fixes"? :)
>>> Sascha
>> My point is that it was tagged in the middle of active bug fixing that
>> applies to 3.0.x series.  Why not wait until the bug fixing is over? We're
>> talking about a day or two.  Again, I see no point in releasing (updating)
>> damaged goods with the known fix at hand.
>> John

More information about the Kernel mailing list