On Tue, 6 Feb 2001, Amir Karger wrote:
> On Tue, Feb 06, 2001 at 04:59:41PM +0100, Michael Schmitt wrote:
> >
> > PS: I noticed that there is some debate on what should go into 1.1.6fix2 and
> > what should only be part of 1.2. From a user's point of view, I appreciate any
> > improvements that are quickly accessable and only require minor local changes
> > to LyX. E.g. a new layout file should not affect the overall stability of LyX
> > (e.g. numbering of foils/better seminar class). The same applies to new key
> > bindings. Even an automatic PDF preamble (which I asked for some time ago)
> > should not cause bigger harm even if it requires some additional code lines.
> > IMHO there is a clear distinction between minor fixes/improvements and more
> > fundamental changes such as a new GUI that should only go into the development
> > branch. Well, as I said, it's just my personal opinion.
>
> I don't know how many of the core devvies agree with me here (I'm not one)
> but the fix series is supposed to be FIXes. The whole point is that every
> fix release should be *at least* as bug free as the previous release. And if
> you've done any coding at all, you know that even adding "minor local
> changes" to a program can often lead to bugs.
>
> The LyX code development model has gone through a number of changes. I think
> people eventually decided to make the fix branch extremely conservative
> because we just don't have enough coders to have an evolving "stable" branch
> like we used to. With so few coders, they need to devote their time to
> developing the unstable branch, while devoting smaller amounts of time to
In other words: "stable advancement" of the trunk and rock solid release
branches.
The release cycle of the new code on the trunk should be short enough that
new releases supporting wonderful new features come out sooner than what a
split development process would allow.
> fixing the fix branch. If we get, say, 5 new coders who are willing to spend
> a lot of time on LyX (without losing others), then we might have the time to
> have a stable branch that gets new features in it.
New developers yes, split development/stable branches no. With a small
enthusiastic crew we've managed some fantastic gains in the last 12
months. Why go back to the old development process when any new developers
can help get new releases stable sooner and add new features there where
they belong not to older releases. This requires a commitment from
everyone to at least quarterly releases or IMO monthly releases in
conjunction with LDN issues ;-) Not that there's any shortage of news or
other stuff to write about.
Allan. (ARRae)
P.S. Of course, everyone will have noticed by now that LDN takes me away
from coding so I get to be opinionated, make demands of developers and
wonder what is happening in the sources :-)
