[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stable releases
From: |
address@hidden |
Subject: |
Re: Stable releases |
Date: |
Tue, 17 Jan 2012 10:07:12 +0100 |
On Jan 17, 2012, at 10:01 AM, Werner LEMBERG wrote:
>>> Normally, a route to a stable release means a code freeze, applying
>>> only fixes to problems within the code. This also means that no
>>> new bug fixes get applied. Are we going to do the same?
>>
>> I don't understand the difference between the two - wouldn't a bug
>> be a problem within the code?
>
> I was imprecise. With `bug' I mean a bug in rendering music. Fixing
> such a bug can introduce new rendering bugs.
It seems like the two may overlap: for example, a division-by-zero error can
cause insane spring lengths (I fixed a bug like this earlier this year).
I think that, if Carl's all right with taking on this responsibility, he can
give the go-ahead for what constitutes a code fix versus a layout fix. I do
agree with the principal of what you're saying - we should police ourselves as
2.16 approaches to make sure that we're not introducing material that goes
against the Irish proverb "may the cure not be worse than the disease" (or
something like that...).
Cheers,
MS
- Re: Stable releases, (continued)
Re: Stable releases, Janek Warchoł, 2012/01/16
- Stable release proposal, Carl Sorensen, 2012/01/16
- Re: Stable release proposal, Keith OHara, 2012/01/17
- Re: Stable release proposal, Francisco Vila, 2012/01/17
- Re: Stable release proposal, Trevor Daniels, 2012/01/17
- Re: Stable release proposal, David Kastrup, 2012/01/17
- Re: Stable release proposal, Werner LEMBERG, 2012/01/17
- Re: Stable release proposal, Janek Warchoł, 2012/01/17