Shared library annoyance with gcc-3_0-branch

[H . J . Lu]

On Sun, Feb 18, 2001 at 11:39:36AM -0500, dewar@gnat.com wrote:
> 
> Well you can't expect people to upgrade their systems to new releases
> too often for several reasons including:
> 
> 1. Installing and qualifying a new release is a huge effort in a large
> project.

That is true for both gcc and binutils themselves.

> 
> 2. Going to a new release is only worthwhile if it addresses major
> significant problems.

Different people have different definitions of "major" and
"significant".

> 
> 3. Even with the most strenuous regression testing (which is typically
> not done for most major gcc components, this is not a criticism, just
> an observation on what can be achieved with current resources), you
> will still have regressions between releases, and these regressions
> can be deadly to critical schedules.
> 
> So a more frequent release schedule has the inevitable effect of 
> increasing the number of versions in active use. That's not necessarily
> a bad thing, but it makes the support effort that much more difficult.
> 
> Developers often like to take the viewpoint "just upgrade to the latest
> version, your bug is fixed there", but that's an impractical attitude
> for a project that has base lined on an older version.
> 

I agree with you on that.

What I'd like to see are

1. Make both stable and unstable releases.
2. Tell people to use the stable release and try unstable one if
everthing else fails.
3. Fix the unstable release as quickly as we can.
4. Make the unstable release as often as we can.

That is basically what I have been doing for the Linux binutils. I
am just making unstable releases for Linux. But since my new releases
come out so often, my current release has much less bugs than the FSF
binutils. But qualifying a new binutils release is a huge effort, even
just for Linux/ia32 only. I don't see my Linux binutils will be
qualified on other Linux platforms, let alone any other platforms.
People who care about those platforms have to do it.

-- 
H.J. Lu (hjl@valinux.com)