[Cubicweb] CW app distribution with a not brand new cw version

Sylvain Thénault sylvain.thenault at logilab.fr
Tue Apr 20 17:19:26 CEST 2010

On 20 avril 08:58, Florent Cayré wrote:
> Has your debian specialist and package maintainer any clue on this topic ?

Attached is my proposal of how we could handle this. Let's discuss it here,
I'll publish it and we'll start applying it when a consensus will be reached.

Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

-------------- next part --------------
Configuration management with the debian packaging system

This is a proposal to acheive proper configuration management for cubicweb using
the debian packaging system. The idea of this proposal is centered on a version
numbering scheme. This has some cons (see the conclusion) but is still imo the
cheapiest way (and maybe the only maintainable way in long-term) to get things
working properly in this area.

Please provides feedback, other ideas, enhancements to the process, etc...


1. configuration management of cubicweb applications (though that should be
   generalizable to other projects)

2. something like `apt-get install cubicweb=3.8.2` working, with proper
   dependencies finally installed

3. no cubicweb upgrade if an installed cube doesn't work with the new version

4. limit number of debian repositories

Numbering scheme
Based on the standard 3 number scheme: ::


* increments Z for bug fixes release
* increments Y for backward compatible evolutions release
* increments Y for release breaking backward compats of public api

(everywhere of course, eg even in cubes, not only in cubicweb).

Then we can set in a cube tested with cubicweb X.Y::

  Conflicts: cubicweb-common >= X+1

even though that X+1 release doesn't exist yet.

This, together with proper `Depends` field, should acheive goals 1 and 3.

Apt extension

Currently, apt-get install isn't able to look for needed version of
[reverse-]dependencies when trying to install a specific version.

Hence we should develop a command to get the whole versioned dependencies and
reverse dependencies by analysing `apt-cache search` results. The result of this
command could then  be given to `apt-get install` (which will eventually
detect conflicts with already installed packages).

This should acheive goals 2.



* when a X+1 version is going out, this may triggers a lot of package
  republication (even though they may actually not be affected by the api change)

  - don't do that with cubicweb's dependency such as lgc, rql, yams, but use
    explicit conflicts in those packages?

  - a cubicweb standard library should limit the number of affected cube

* X may increment fast

Whats to be done:

* the dependencies version detection command (constraint solver)

* always properly set Depends and Conflicts in packages

* tie to the version numbering scheme in all of our projects

* properly defines what api is public or not so one can still reserve
  some room for changes without needing a X+1 release

* for customer projects, you should either:

  - setup a custom repository, ensuring public repositories aren't referenced
    in sources.list

  - depends on cubicweb-common=X.Y.Z or cubicweb-common <= X.Y+1

  to either block undesired upgrade or only keep bug fix release upgrade


* will maintain two public debian repositories: logilab-public and
  logilab-public-stable. The first one being kindof staging place for test of
  packages before they are allowed to move on the stable one.

* may decide everytime (once a year) to kill the bw compat code and procuce
  a X+1 release

More information about the Cubicweb mailing list