Stephen J Baker wrote:
> Could I plead for 3.1 to progress to 3.2 as soon as it's stable,
> then to maintain 3.2 as the "stable" release with new dev going
> into 3.3 (kinda like the Linux kernel dev advances). That somewhat
> removes the pressure to cycle major versions quite so quickly.
I'd go along with this.
> There were quite a few simple fixes that could have gone into 3.0.n
> that have been delayed for too long while we wait for 3.1. to appear.
Yup, sorry.
> The odd/even model
> for code release is much more appropriate now than it was in
> the Mesa 2.x era because there are now so many more people dabbling
> in the core code.
And with CVS, having two branches is a bit easier for us to cope with.
> There is also the (unresolved) issue of the Mesa numbering scheme
> in relation to the library name requirements of opengl/linux-base
> proposal. That needs to be resolved before we release 3.1/3.2
> because 3.1 switches us to libGL.so as the installation location
> rather than libMesaGL.so and if we call it libGL.so.3.1 we'll
> cause problems later when/if the OpenGL spec revision ever gets
> that high.
>
> That means that we have a one-shot chance to sort the naming issue
> out *before* 3.1 is released - and it makes sense (to me at least)
> to decide on the odd/even numbering at the same time.
I think we all agree that the library name should be
"libGL.so.1.2.something"
Josh's suggestion for something=030100 is good, even though I doubt
there'd be more than 9 patch levels to a given release.
If we don't encode the Mesa version in the "something" part, people
may wonder what version of Mesa they have (it might not even be a
Mesa implementation; consider Metrolink or Xi).
I guess "strings libGL.so.1.2 | grep Mesa" would be the answer.
-Brian
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
