On Tue, 8 Jun 1999, Brian Paul wrote:

> > The real question is whether Brian wants the next release version to
> > include the new code or not.
> 
> I don't have a date in mind for the next beta release.
> 
> I'd like to keep the mainline code pretty much stable.  After Keith
> has tested and debugged his code branch with most of the demo/sample
> programs, Quake, etc. then merging into the mainline is appropriate.
> 
> In other words, when people download and test the latest CVS snapshot
> I'd like them to see forward progress (fewer bugs, better speed)
> rather than find newly broken code.
> 
> I was planning on doing more conformance testing/fixing pretty soon.
> I'd rather do that with stable, mainline code.
> 
> Keith, I'd like to hear what your longer-term coding plans are.  Do
> you see a milestone in your work for a 3.1 release?
 
Perhaps it's time for Mesa to go to the dual-stream approach of the
Linux Kernel and other packages like The GIMP where odd numbered
releases are where new code goes and even numbered get all the bug
fixes.

In this case, that would mean finding a reasonably usable 3.1 and
releasing it as 3.2.0 - with the expectation that we'd have to fix
bugs in it to make progressively more stable 3.2.1, 3.2.2, etc.

Meanwhile (and pretty much simultaneous with the release of 3.2.0
would come 3.3.0 which would be where all the major new features
and fancy new algorithms go. When eventually, 3.3.N is stable enough,
it becomese 3.4.0 and again, new features go into the odd numbered
release 3.5.0.

This would be valuable I think because there are times when bugs
appear in 3.0 that it would be nice to fix - without having to
suffer the growing pains of 3.1

The obvious downside is that bug fixes have to be applied to two
releases at once - but I think that's a reasonable price to pay
for the benefits of a progressively more stable current release.

That in turn means that you don't have to worry so much about
converting the current odd-numbered release into an even numbered
one for the sake of fixing bugs.

I don't think this approach is a good idea for small projects
in their early stages - but for something as large and long-lived
as Mesa, I think it's a good idea.

One SPECIFIC reason to go this way is that it gives people
writing low level drivers a stable (even numbered) platform
to work with.

What does everyone else think about this idea?

Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: [EMAIL PROTECTED]      http://www.hti.com
Home: [EMAIL PROTECTED] http://web2.airmail.net/sjbaker1



_______________________________________________
Mesa-dev maillist  -  [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev

Reply via email to