KDE 3.2 release plan=?iso-8859-1?q?notice
Daniel Stone
dstone at kde.org
Wed Jun 18 13:12:51 BST 2003
On Wed, Jun 18, 2003 at 02:01:33PM +0200, Oswald Buddenhagen wrote:
> at this point it becomes obvious that we _know_ that RC1 won't be in a
> releaseable state, which means that it simply is no RC. what exactly
> speaks against calling these realease-non-candidates "pre"?
It is an RC. If I was able to find out where every single bug was in KDE
and how to fix them, we could make a flawless RC. It's just
realistically taking into account that some things will be broken,
either in our out of the framework of the release cycle. Claiming they
won't, and that the release cycle will be problem-free, is pretty naive;
previous experience shows this.
> my understanding or the terminology is this:
> - snapshot, pre-alpha: everything is open
Well, exercise some restraint, and start slowing down a bit.
> - beta: there are no known major bugs
More or less.
> - rc: we honestly think that we can release it: the thing is virtually
> bug-free according to our best knowledge. only minor bugs in less
> prominent places are allowed.
We'd never get a release then. :( People are far more likely to test RCs
than betas. Having more RCs thus helps us guarantee a better -final.
> btw, somebody has to explain to me, what this "The HEAD branch is frozen
> for feature commits that are not listed in the planned-feature
> document." stuff is supposed to be good for. either you get ready before
> the real feature freeze or you don't - so why put such an arbitrary
> restriction on spontaneous creativity?
Well, it prevents the tree from being polluted by useless crap. You
probably don't want anything that major that's spontaneous in a release.
> += 2-3 weeks: Pre1
>
> The i18n strings are frozen.
> Any non-trivial patches to CVS have to be approved by at least
> one other related developer.
>
> This is not called gamma or final beta, as it is not released. Still,
> packagers are encouraged to make experimental packages.
>
> += 1 week: Pre2
Isn't that just the same as RCs, only with a different name??
> += 1 week
> If no showstoppers are known by now, this will be RC1, otherwise
> another Pre.
> Repeat until success.
>
> += 1 week
> If no showstoppers are known by now, release 3.2, otherwise fix the
> bugs and create and create another RC (one or two days later).
> Repeat until success.
I really don't see how what you're proposing is different, apart from 3
letters.
> as you see, this is roughly the same as the previous schedule - just that
> the terminology is more standard.
alpha/beta/rc is very, very well-understood, and, more importantly, it's
what all the developers are used to. Why change for no benefit?
--
Daniel Stone <daniel at raging.dropbear.id.au> <dstone at kde.org>
KDE: Konquering a desktop near you - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030618/5b7b0caa/attachment.sig>
More information about the kde-core-devel
mailing list