Re: Release of 2.4.21

[David Lang]

hopefully we won't have a steady stream of critical bugs. if we do we need
to stop new development and find out where we are going wrong.

after all this isn't microsoft.

one advantage of useing a good version control system is that it should be
very easy to make a minor update to 2.4.20 to produce 2.4.21 without it
being a major disruption to things and then continue with the existing
development. from what I understand about bk it should make it even
easier.

I don't like going to 4 part version numbers. if this was a marketing
driven company that had promised features in 2.4.21 and they aren't ready
but a new version is needed then we would have a reason to do a 2.4.20.1
so that we don't have to deal with broken promises, but sine we aren't in
that situation I don't see why the 2.4.20.N is needed.

Every other time there has been a critical bug it was fixed in the next
normal release number (or if it's critical enough it was handled  by
rushing a version with just that fix like happened with 2.2)

David Lang

On Thu, 20 Mar 2003, Jeff Garzik wrote:

> Date: Thu, 20 Mar 2003 15:53:38 -0500
> From: Jeff Garzik <[e-mail]>
> To: Christoph Hellwig <[e-mail]>, [e-mail],
>      [e-mail]
> Subject: Re: Release of 2.4.21
>
> On Thu, Mar 20, 2003 at 08:42:18PM +0000, Christoph Hellwig wrote:
> > On Thu, Mar 20, 2003 at 03:34:07PM -0500, Jeff Garzik wrote:
> > > For critical fixes, release a 2.4.20.1, 2.4.20.2, etc.  Don't disrupt
> > > the 2.4.21-pre cycle, that would be less productive than just patching
> > > 2.4.20 and rolling a separate release off of that.
> >
> > I think the naming is illogical.  If there's a bugfix-only release
>
> Many, many companies seem to find it logical.  If you want to squeeze
> a version in between "1" and "2".
>
> Further, other kernel hackers suggested the 2.4.20.N sequence,
> I simply agreed with it.  So it's not only me who thinks this way :)
>
>
> > it whould have normal incremental numbers.  So if marcelo want's
> > it he should clone a tree of at 2.4.20, apply the essential patches
> > and bump the version number in the normal 2.4 tree to 2.4.22-pre1
>
> Human nature says that will drag out the -pre tree ad infinitum.
> Suppose a 2.4.21 is released today, with 2.4.20 + bug fixes.  Now,
> tomorrow, another "critical bug" comes out, and then the -pre tree
> becomes 2.4.23-pre.  Add another critical bug, and I hope you see
> the continual delay of -pre happens here...
>
> The basic logic is "do not disrupt current plans.  Do something
> _in addition to_ current plans."
>
> 	Jeff
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>