[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Where to put post-2.2 development
From:       Michael =?iso-8859-1?q?H=E4ckel?= <Michael () Haeckel ! Net>
Date:       2001-09-20 13:42:47
[Download RAW message or body]

On Thursday 20 September 2001 14:19, Marc Mutz wrote:
>
> I was talking about applications here, not core libraries. What's wrong
> with "add one feature, then release new x.y" and "fix a bunch of small
> bugs or one big one and release a new x.y.z"? Most users don't track
> the releases anyway. They depend on the distros to filter for them.
>
> If you look at other applications, a release is always done when a major
> bug was fixed. KMail had to wait one month before releasing fixes for
> major bugs that where fixed after days or weeks at the latest.

Very important bugfixes can always be backported, in this case to the 
KDE_2_2_BRANCH. But that should only be done for really important things, to 
not introduce new bugs in a rarely tested branch.

Also, if we release a new version of KMail, always, when a bug has been fixed, 
then we have to release nearly daily :-)

> This concept does only work, though, if we don't abandon "old" versions
> too early. It's of course too much to ask for fixing minor bugs in
> 2.1.x now, but major bugs like the 1E9S bug in KMail 1.0.x should have
> been fixed (Waldo had a patch for that :-( ).

That was discussed months ago and we decided against that, because KMail 1.0.x 
has also many other major problems. For example it violates some RFCs.

Also between releasing something and get people to use it is still a big gap.
For example in KMail there were some critical bugfixes for mail eating bugs in 
1.0.29 and later, but most distributions still shipped the old KMail 1.0.28, 
that came with KDE 1.1.2.

> > Besides, working toward a release means a feature freeze and a
> > bug-fix period. These are needed for a good bug-free product. In
> > light of that I doubt that this idea will create more stable software
> > in the long run.
>
> If the steps are smaller, then the bugs will be easier to pin down, IMO.

Sorry, but new features and big changes simple require some time, lets say, at 
least two betas, to get enough testing.
More frequent releases make big changes difficult.

For example we do have now the highly requested feature SMTP authentication 
since some time in CVS, but I still have not recieved any feedback on it yet.

Well, but maybe it is just bug free :-)

Nevertheless, every application maintainer is of course free, to release his 
application when he wants to.

Regards,
Michael Häckel

[prev in list] [next in list] [prev in thread] [next in thread]