[Kolab-devel] Kolab 2.0 Release Coordination

Thomas Lotterer thl at dev.de.cw.com
Tue Jul 6 15:13:54 CEST 2004


On Wed, Jun 30, 2004, Richard Bos wrote:
> 
> I have a discussion with Steffen about the version and release
> numbering [...]
> 
I posted a quite length article with a suggestion about
vendor version numbering to this list a while ago, see
http://kolab.org/pipermail/kolab-devel/2004-January/000794.html

In the context of Kolab we should be picky when to use the term
"Version" vs. "Release". The former is more or less a enumeration of
each individual component and is completely independent from other
components. The latter tags a whole collection of components which are
going to be used together, so this tag has to be added to the overall
packaging mechanism. The "Version" must be visible in the tarball, the
"Release" must be visible in the packaging.

Examples with names and numbers ARBITRARY CHOSEN using OSSP "Version"
scheme and OpenPKG "Release" packaging scheme.

    vendor "Version" and tarball
    ============================

    minor improvements, new features
    possibly incompatible:
    --------------------------------
    o  kolab-1.8.0.tar.gz
    o  kolab-1.9.0.tar.gz
    o  kolab-1.10.0.tar.gz
    o  kolab-1.11a1.tar.gz #alpha1
    o  kolab-1.11a2.tar.gz #alpha2
    o  kolab-1.11b1.tar.gz #beta1
    o  kolab-1.11.0.tar.gz

    minor portability, cosmetic and security fixes
    fully (even bug-) compatible:
    ----------------------------------------------
    o  kolab-1.10.0.tar.gz
    o  kolab-1.10.1.tar.gz
    o  kolab-1.10.2.tar.gz

    major improvements and complete redesign
    likely incompatible, upgrade needs data conversion:
    ---------------------------------------------------
    o  kolab-1.10.2.tar.gz
    o  kolab-2.0.0.tar.gz

Numbers are cheap. If the date should be included in the vendor
"Version" I recommend avoiding dashes and underscores and use dots
instead. It might be useful to replacing the last digit as shown in the
third example)

    o  kolab-1.9.0.20040102.tar.gz
    o  kolab-1.9.0.20040304.tar.gz
    o  kolab-1.9.20040506.tar.gz

    package "Release"
    =================

    OpenPKG CURRENT using YYYYMMDD tag
    ----------------------------------
    o  kolab-1.9.0-20040702.src.rpm
    o  kolab-webadmin-0.2.4-20040701.src.rpm
    o  kolab-resource-handlers-0.2.2-20040702.src.rpm

    OpenPKG RELEASE 1.3
    -------------------
    o  kolab-1.9.0-1.3.0.src.rpm
    o  kolab-webadmin-0.2.4-1.3.0.src.rpm
    o  kolab-webadmin-0.2.4-1.3.1.src.rpm #security patch
    o  kolab-resource-handlers-0.2.2-1.3.0.src.rpm

    private OpenPKG packages (assuming 1.2.kolab.3.x tag)
    -----------------------------------------------------
    o  kolab-1.9.0-1.2.kolab.3.0.src.rpm
    o  kolab-webadmin-0.2.4-1.2.kolab.3.0.src.rpm
    o  kolab-webadmin-0.2.4-1.2.kolab.3.1.src.rpm #security patch
    o  kolab-resource-handlers-0.2.2-1.2.kolab.3.0.src.rpm

OpenPKG name-version-release file naming supports private packages.
The supplier must ensure they do not conflict with official release
numbering which is true if a name is included. Numbers are optional and
can appear before or past the name. Any number of dots is allowed. Note
that RPM uses dots to build groups for version comparison, i.e. foo10 is
older than foo2 but foo.10 is newer than foo.2. There is no rule for the
name part.

The current scheme used by Kolab does not allow the end user to identify
whether a package was created by Kolab or OpenPKG. At the point
Kroupware ran there was no "private package" recommendation available
from OpenPKG but now it's time to change.

In the end I'd love to see something like this in obmtool.conf for the
daily development

    @install ${loc}vim-6.2.504-kolab.1.20040426
    @install ${loc}dcron-2.9-20040207
    @install ${loc}kolab-1.9.0-kolab.1.20040702 --without=genuine
    @install ${loc}kolab-webadmin-0.2.4-kolab.1.20040702
    @install ${loc}kolab-resource-handlers-0.2.2-kolab.1.20040702

and this for a "Kolab Release"

    @install ${loc}vim-6.2.504-kolab.1.7.0
    @install ${loc}dcron-2.9-1.7.0
    @install ${loc}kolab-1.9.0-kolab.1.7.0 --without=genuine
    @install ${loc}kolab-webadmin-0.3.1-kolab.1.7.1
    @install ${loc}kolab-resource-handlers-0.4.0-kolab.1.7.0

Can you see 
- whether they are shipping a OpenPKG vim packge verbatim or their modified package?
- which package received a security update within the "Kolab Release"?
Then you understand ...

--
Thomas.Lotterer at cw.com, Cable & Wireless




More information about the devel mailing list