[Kolab-devel] Kolab Naming (was Kolab-CF)

[Thomas Lotterer]

On Mon, Jan 19, 2004, Stephan Buys wrote:

> I would suggest:
> 
> kolabd (kolab engine is also a nice name)
> and 
> kolab-webadmin
> 
> But is there a concept for a Kolab server version? At the moment we
> are using OpenPKG-current so it is very hard to stay static with certain
> versions? Also, I have no idea how Kolab versions differ from the kolab rpms.
> 
Thanks to Stephan for pointing me to this list. I wasn't subscribed
until yesterday, so I had to browse the archive to become current. Sorry
for the delay.

> Maybe Thomas could make some suggestions around versioning, also
> specifically around OpenPKG-2.0, which is coming soon. We could possibly
> follow OpenPKG in the sense that "Kolab Server" follows OpenPKG, the same 
> way that KDE follows QT as far as major versioning is concerned.
> 
> Ie. Kolab-2.0 will be the version of packages and backend services that
> are catered to run with OpenPKG 2.0? 
> 
OpenPKG is about packaging applications where Kolab is one of them.
Development of both projects has too little interrelationship. A huge
change in OpenPKG might have zero impact in Kolab and vice versa. Users
expect visible (commercial world) and/or technological (open source
world) differences when the major number changes. After OpenPKG v1.3
we had some internal debates whether the next version should be v1.4
or v2.0. Based on user expectations a v1.4 would be better, but due to
technological changes and engineering requirements we have to use v2.0,
see http://cvs.openpkg.org/chngview?cn=14255

My conclusion here is I believe it is a good idea for Kolab to follow
the OpenPKG version style but it is not a good idea for Kolab to follow
the actual OpenPKG numbers.

The OpenPKG (and also OSSP) style in very short: x.y.z where
 x = major changes, technological changes; often incompatible
 y = minor changes, small improvements; mostly backwards compatible
 z = bug/security fixes; fully compatible (brain-dead drop in replacement)

> In the mean time we continue improving the backend services, with major 
> upgrades/architectural changes applied when OpenPKG bumps up in version?
> 
> Please lets have everybody's suggestions! 
> 
Here is what i already sent to Bernhard, Martin, Tassilo and Stephan
triggered by http://lists.kde.org/?l=kroupware&m=107331084231769&w=2

> - if we talk about two pieces of code, it's best to keep them in two CVS
>   modules. This will lead to two separate tarballs and independent version
>   numbering. Version confusion will vanish.
> 
> - if the two pieces of code are not independent of each other, in this
>   case the web interface must be installed on the same server as the
>   backend glue code, then it's best to keep them in a single CVS module.
>   They should be treated as a single program with a single tarball and a
>   unified number. Version confusion will vanish.
> 
> - in any case, (sub|alpha|beta|...)releases have to be tagged properly
>   and the tags have to be kept forever (or a long time). Moving tags is
>   black magic and voodoo as it inhibits examiniation of past issues.
> 
> - it would be helpful if the module(s) come with a automated mechanism
>   to alter version, CVS tag, substitute text, create and upload tarball.
>   etc. We have done this for all OSSP projects, so i could help here.
> 
> - the current relationship of Kolab and OpenPKG does no longer require any
>   Kolab patches to OpenPKG so Kolab could be reduced to it's own code.
>   Even if future development of Kolab might temporarily require OpenPKG
>   SRPM patching this should be the exception not the rule as it was in
>   the beginnings of Kolab. This means the CVS module(s) could be cleaned
>   up and reduced to a minimum.
> 
> - [mirrors] this sounds like an approach from the past millenium. Nobody cares
>   about bandwidth today. Keep in mind that the project can be reduced to one
>   or two modules aka tarballs. There is no need to publish OpenPKG-like
>   packages anymore as pristine OpenPKG packages were tailored to fulfil
>   kolab needs and are readily available for download. If you require
>   a snapshot-like environment more current than a release but not the
>   everchanging CURRENT branch - that's what we provide the ZfOS/kolab
>   download site for. It has virtually unlimited bandwidth.
> 
> PS: OpenPKG v2.0 is scheduled to be finished on mid-Feb-2004 and
>     released end-Feb-2004. I would really appreciate if you could
>     incorporate my change requests and improvment suggestions in this
>     or next week so we could include a useful "kolab" package in the
>     release.

Having that said and now knowing about kolab-cf my recommenation is to create
at least three packages,

 kolab-admin
 kolab-glueie (intevation/erfrakon) requiring admin, conflicts with gluecf
 kolab-gluecf (code fusion)         requiring admin, conflicts with glueie

Additonal packages might be

 kolab-webui (horde webmail) requiring ...
 kolab-ogo   (I know somebody is working on it)

Just to let my thoughts fly: if a webmailer could be used for other
OpenPKG environments it might change to something like "ogo" having a
"with_kolab" option. But this is entirely hypothetical.

Of course, the names are up to you. I would recommend using two strings,
dash delimited, the first one being a constant "kolab" prefix. This
circumvents name space collisions with OpenPKG and maximizes chances
OpenPKG imports the packages verbatim. Do not use multiple dashes, it
might break various scripts that try to extract the package name out of
filename. Only one package in OpenPKG has this bad habit and we better
remove that exception but to create another one.

Much stuff to discuss, folks.

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