On Tue, Jan 25, 2011 at 12:25 PM, wrote:
> Hi Gilles,
>
> - "Gilles Sadowski" a écrit :
>
>> > >> >> >> 1) s/2.2/3.0 s/3.0/4.0
>> > >> >> >> 2) abandon 2.2 release
>> > >> >
>> > >> > From the fact that you have to consider these options, let's
>> remember that,
>> > >> > at the release of
Hi Gilles,
- "Gilles Sadowski" a écrit :
> > >> >> >> 1) s/2.2/3.0 s/3.0/4.0
> > >> >> >> 2) abandon 2.2 release
> > >> >
> > >> > From the fact that you have to consider these options, let's
> remember that,
> > >> > at the release of 3.0, we should immediately create a
> "bug-fix-only" br
> >> >> >> 1) s/2.2/3.0 s/3.0/4.0
> >> >> >> 2) abandon 2.2 release
> >> >
> >> > From the fact that you have to consider these options, let's remember
> >> > that,
> >> > at the release of 3.0, we should immediately create a "bug-fix-only"
> >> > branch
> >> > (destined to remain backward compa
On Tue, Jan 25, 2011 at 9:54 AM, Gilles Sadowski
wrote:
> Phil,
>
>> >> >> I guess there are some other logical alternatives to consider:
>> >> >>
>> >> >> 1) s/2.2/3.0 s/3.0/4.0
>> >> >> 2) abandon 2.2 release
>> >
>> > From the fact that you have to consider these options, let's remember that,
Phil,
> >> >> I guess there are some other logical alternatives to consider:
> >> >>
> >> >> 1) s/2.2/3.0 s/3.0/4.0
> >> >> 2) abandon 2.2 release
> >
> > From the fact that you have to consider these options, let's remember that,
> > at the release of 3.0, we should immediately create a "bug-fix
On Tue, Jan 25, 2011 at 7:56 AM, Gilles Sadowski
wrote:
> Hi.
>
>> >> I guess there are some other logical alternatives to consider:
>> >>
>> >> 1) s/2.2/3.0 s/3.0/4.0
>> >> 2) abandon 2.2 release
>
> From the fact that you have to consider these options, let's remember that,
> at the release of
Hi.
> >> I guess there are some other logical alternatives to consider:
> >>
> >> 1) s/2.2/3.0 s/3.0/4.0
> >> 2) abandon 2.2 release
>From the fact that you have to consider these options, let's remember that,
at the release of 3.0, we should immediately create a "bug-fix-only" branch
(destined
On Mon, Jan 24, 2011 at 11:01 AM, wrote:
>
> - "Phil Steitz" a écrit :
>
>> On Mon, Jan 24, 2011 at 7:58 AM, wrote:
>> >
>> > - "Phil Steitz" a écrit :
>> >
>> >> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz
>>
>> >> wrote:
>> >> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz
>>
>>
On Mon, Jan 24, 2011 at 11:04 AM, wrote:
>
> - "Phil Steitz" a écrit :
>
>> I guess there are some other logical alternatives to consider:
>>
>> 1) s/2.2/3.0 s/3.0/4.0
>> 2) abandon 2.2 release
>>
>> Option 1) may not be that bad - saves work reverting the incompatible
>> stuff remaining an
- "Phil Steitz" a écrit :
> I guess there are some other logical alternatives to consider:
>
> 1) s/2.2/3.0 s/3.0/4.0
> 2) abandon 2.2 release
>
> Option 1) may not be that bad - saves work reverting the incompatible
> stuff remaining and solves Luc's (and anyone else who has been using
>
- "Phil Steitz" a écrit :
> On Mon, Jan 24, 2011 at 7:58 AM, wrote:
> >
> > - "Phil Steitz" a écrit :
> >
> >> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz
>
> >> wrote:
> >> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz
>
> >> wrote:
> >> >> The clirr report run from the current M
I guess there are some other logical alternatives to consider:
1) s/2.2/3.0 s/3.0/4.0
2) abandon 2.2 release
Option 1) may not be that bad - saves work reverting the incompatible
stuff remaining and solves Luc's (and anyone else who has been using
trunk/2_X) problem and also keeps us consistent
On Mon, Jan 24, 2011 at 7:58 AM, wrote:
>
> - "Phil Steitz" a écrit :
>
>> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz
>> wrote:
>> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz
>> wrote:
>> >> The clirr report run from the current MATH_2_X branch is, as
>> expected,
>> >> problematic.
- "Phil Steitz" a écrit :
> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz
> wrote:
> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz
> wrote:
> >> The clirr report run from the current MATH_2_X branch is, as
> expected,
> >> problematic. To get 2.2. out, we need to agree on what breaks we
>
On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz wrote:
> On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz wrote:
>> The clirr report run from the current MATH_2_X branch is, as expected,
>> problematic. To get 2.2. out, we need to agree on what breaks we are going
>> to allow and what we are going to f
On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz wrote:
> The clirr report run from the current MATH_2_X branch is, as expected,
> problematic. To get 2.2. out, we need to agree on what breaks we are going
> to allow and what we are going to fix. Here is a first cut and proposal
> for some immediate
On Thu, Jan 6, 2011 at 6:55 AM, Gilles Sadowski
wrote:
> Hi.
>
>> The clirr report run from the current MATH_2_X branch is, as expected,
>> problematic. To get 2.2. out, we need to agree on what breaks we are going
>> to allow and what we are going to fix. Here is a first cut and proposal
>> fo
Hi.
> The clirr report run from the current MATH_2_X branch is, as expected,
> problematic. To get 2.2. out, we need to agree on what breaks we are going
> to allow and what we are going to fix. Here is a first cut and proposal
> for some immediate fixes that I would appreciate feedback on.
>
On Sun, Jan 2, 2011 at 5:50 PM, Luc Maisonobe wrote:
> Le 02/01/2011 21:09, Luc Maisonobe a écrit :
> > Hi Phil,
> >
> > Le 02/01/2011 19:01, Phil Steitz a écrit :
> >> The clirr report run from the current MATH_2_X branch is, as expected,
> >> problematic. To get 2.2. out, we need to agree on w
Le 02/01/2011 21:09, Luc Maisonobe a écrit :
> Hi Phil,
>
> Le 02/01/2011 19:01, Phil Steitz a écrit :
>> The clirr report run from the current MATH_2_X branch is, as expected,
>> problematic. To get 2.2. out, we need to agree on what breaks we are going
>> to allow and what we are going to fix.
Hi Phil,
Le 02/01/2011 19:01, Phil Steitz a écrit :
> The clirr report run from the current MATH_2_X branch is, as expected,
> problematic. To get 2.2. out, we need to agree on what breaks we are going
> to allow and what we are going to fix. Here is a first cut and proposal
> for some immediat
2011/1/2 Phil Steitz :
> On Sun, Jan 2, 2011 at 1:42 PM, Mikkel Meyer Andersen wrote:
>
>> Hi,
>>
>> In general: I understand that removing e.g. functions to an interface
>> is (seriously) breaking compatibility. Why is it just as bad to add
>> e.g. functions to an interface? As far as I know, the
On Sun, Jan 2, 2011 at 1:42 PM, Mikkel Meyer Andersen wrote:
> Hi,
>
> In general: I understand that removing e.g. functions to an interface
> is (seriously) breaking compatibility. Why is it just as bad to add
> e.g. functions to an interface? As far as I know, the binaries are
> still compatibl
Hi,
In general: I understand that removing e.g. functions to an interface
is (seriously) breaking compatibility. Why is it just as bad to add
e.g. functions to an interface? As far as I know, the binaries are
still compatible, so where does this "adding breaks compatibility"
stem from? And is it o
The clirr report run from the current MATH_2_X branch is, as expected,
problematic. To get 2.2. out, we need to agree on what breaks we are going
to allow and what we are going to fix. Here is a first cut and proposal
for some immediate fixes that I would appreciate feedback on.
0) The improve
25 matches
Mail list logo
