From koffice Fri Oct 06 15:48:15 2000 From: Andreas Lauser Date: Fri, 06 Oct 2000 15:48:15 +0000 To: koffice Subject: Re: KDE2 release schedule update X-MARC-Message: https://marc.info/?l=koffice&m=97084725824983 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