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

List:       koffice
Subject:    Re: KDE2 release schedule update
From:       Andreas Lauser <andlaus () gmx ! de>
Date:       2000-10-06 15:48:15
[Download RAW message or body]

Sorry a bit of topic, but I couldn't resist ;-)

On Thu, 05 Oct 2000, Hans Meine wrote:
> > I also would like to see a split up of release schedules based on
> > packages. This schedule still seems to be based on "release everything
> > together". We want more releases more often and this schedules doesn't
> > reflect that.
>
> This is a serious issue. I talked with the aRts-dude Stefan about that.
> Arts has much potential and was release separately from KDE in the past and
> now it would suffer much from big, monolithic, seldom KDE releases. There
> are more examples (mosfet et al) for things which should (and could, that's
> the fact) be given to the user in less than half a year after KDE 2.0.

What about releasing every package for its own (depending on its development 
pace) and after some time (about 1 or 2 months) release all the current 
stable packages available together in a monolithic release (like 2.0.1, etc). 
for the more advanced users this would offer the possibility to update the 
needed packages while the less advanced users could wait until the same 
packages were released together in a monolithic release. Addidionally the 
package maintainers would have the possibility to leave out one or two minor 
releases if they think that their packages are not 'end user ready'. At the 
other side they could release stable versions between these monolithic 
releases which wouldn't force them to do nothing until all the other packages 
would be ready.
   Of course there would be more concerns about binary compatibility, but if 
only the "major" releases (eg: 2.1.0) included new versions of the libs this 
wouldn't be such a big deal IMHO.

> > > - February/March 2001 - KDE2 1.1 release.
>
> ..which seems to be quite late from THAT point of view.
> MMaybe we can release kdelibs, kdebase and/or others seperately in binary
> compatible shape more often?

-- AND

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