[dev] Re: [cvs] commit: horde/lib version.php

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at bigworm.colorado.edu>:

> Quoting Jan Schneider <jan at horde.org>:
>
> | Zitat von Michael M Slusarz <slusarz at bigworm.colorado.edu>:
> |
> | > slusarz     2003/08/04 09:34:12 PDT
> | >
> | >   Modified files:        (Branch: RELENG_2)
> | >     lib                  version.php
> | >   Log:
> | >   Tarball script: building new horde release - 2.2.4
> |
> | I thought we learned from the last time, that we should *always*
> release
> | RCs
> | before a new version. Beside that the translators didn't have any time
> to
> | update their translations.
>
> Hmmm, I thought we decided differently.  For security/bug-fix releases
> (i.e.
> minor releases) I thought we weren't going to go through RCs.  RCs were
> only for major releases (e.g. Horde 2.3.0).

No, I don't think so.

1) The last time we introduced a bug with code from a new minor release so
we had to release another version right after. This might always happen if
there is more than one change since the last release or if the changes were
done recently.

2) I don't think this was mainly a security fix. The session fixation code
has been there for a long time, so it seems to not be such a big hole. The
HTML viewer fixes neither, because we know and explicitely tell the admins
that this viewer is unsafe.

3) If we have a security leak that needs to be plugged immediately, it is
the common way to release a new minor version that *only* contains the fix
for that leak.

4) RCs are necessary for every release (except 3) because many translators
only update their translations when there is a new (minor) release cycle
starting because they don't translate on CVS versions.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft