RE: [RFC] stdcxx release process, second draft

[Eric Lemings <Er...@roguewave.com>]

 
The scope of this issue is rather large for a minor release...IMHO.

Brad.

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Tuesday, November 27, 2007 9:59 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [RFC] stdcxx release process, second draft
> 
> So here's a question: do we think STDCXX-336 doable for 4.2.1?
> 
> Martin
> 
> Farid Zaripov wrote:
> >> Martin Sebor wrote:
> >>> I've incorporated everyone's feedback and committed an 
> >> updated version 
> >>> with a number of enhancements of my own. Among the most 
> >> important are 
> >>> the new Goals section with suggested frequencies of 
> >> releases, and the 
> >>> integration of the Version Policy (I plan to delete 
> versions.html). 
> >>> Let me know what you think.
> >>>
> >>>     http://incubator.apache.org/stdcxx/releases.html
> >>>
> >   
> >   I have no objections on this document.
> > 
> > 
> >   Here the some examples (the only source incompatible changes):
> > 
> > 1. Source incompatible changes
> > 
> > 1.1. Merging two or more overloaded functions/methods in one using
> > default parameters:
> >       I.e. replacing void std::vector::resize (size_type) and void
> > std::vector::resize (size_type, value_type)
> > with void std::vector::resize (size_type, value_type = 
> value_type()).
> > 
> > 1.2. Implementing the additional overloads (extensions) of 
> the standard
> > functions/methods:
> >       I.e. adding std::ostream& std::ostream::operator<< 
> (std::ostream&,
> > const wchar*).
> > 
> > 1.3. Adding some function/class in global namespace, that 
> may interfere
> > with user-defined function/class
> >       (i.e without using '__; prefix):
> >       I.e. adding function void print (const char* str) { 
> std::cout <<
> > str << std::endl; } may conflict with user defined
> >       void print (const char* str) { std::printf ("%s", 
> str); } due to
> > multiple function definition.
> > 
> > 1.4. Adding some public/protected methods not specified by standard,
> > that may interfere with user-defined
> >       methods in classes, inherited from the library class.
> > 
> > 1.5. Adding some macros that may accidentally modify the 
> user code: i.e.
> > #define new(p) malloc (p).
> > 
> > 1.6. Moving some declarations from one header file to 
> another without
> > #including the second one in the first
> >       may cause "unknown identifier" compiler error.
> > 
> > 
> > Farid.
> > 
> 
>