RE: C++ binary compatibility between GCC 3.1 and GCC 3.2?

[Bernard Dautrevaux <Dautrevaux at microprocess dot com>]

> -----Original Message-----
> From: Joern Rennecke [mailto:joern.rennecke@superh.com]
> Sent: Monday, July 08, 2002 1:37 PM
> To: Bernard Dautrevaux
> Cc: Gabriel Dos Reis; gcc@gcc.gnu.org; Jakub@superh.com;
> Jelinek@superh.com; Mark Mitchell; obrien@freebsd.org
> Subject: Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?
> 
> 
> Bernard Dautrevaux wrote:
> > 
> > > -----Original Message-----
> > > From: Joern Rennecke [mailto:joern.rennecke@superh.com]
> > > Sent: Saturday, July 06, 2002 10:47 PM
> > > To: Gabriel Dos Reis; gcc@gcc.gnu.org
> > > Cc: Jakub@superh.com; Jelinek@superh.com; Mark Mitchell;
> > > obrien@freebsd.org
> > > Subject: Re: C++ binary compatibility between GCC 3.1 and GCC 3.2?
> > >
> > >
> > > > Thanks for the clarifications.  So all that needs is to make an
> > > > exception to our earlier commitment that minor releases won't
> > > > introduce ABI incompatibility; or make an exception to 
> our scheduled
> > > > development plan.  I don't have any strong opinion.  
> But if we were
> > >
> > Then what was for now named 3.2 byt GCC *developpers* (a 
> much smaller
> > community than gcc *users*) may have to be renamed 3.3 if there is
> > incompatibilities with this 3.2 release (or major change in 
> features), but
> > may just become 3.2.1 otherwise.
> 
> But then you'd have a massive amount of new. possibly 
> destabilizing code
> in 3.2.1 versus 3.2.  Users generally expect a x.y.1 release 
> to me more
> stable than the preceding x.y.0 release.

So the "current" 3.2 branch should provide a 3.3 "release"...

> 
> And, on the other hand, 3.2 would be rather a disappointment regarding
> new features and ports.

I expect a 3.2 version with few new features and ports available soon, with
due comments on why it was done, be less disapointing than one done later
that add new features but also break compatibility. 

With a 
	3.2 == new ABI soon
	3.3 == new features later
split users can switch either now to the new ABI, or later to get both.

With the current scheme they just have
	3.2 == new ABI and new features
but this will only be availabel at the time the 3.3 of the previous scheme
will be. It seems that splitting th eevolution may be less destabilizing for
users and not too much added work for the developpers (not counting the
release manager which obvioulsy will have more work).

        Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
--------------------------------------------