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

[Sylvain Thénault]

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...


Goals
-----

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: ::

  X.Y.Z

* 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.


Conclusion
----------

Cons:

* 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


Logilab:

* 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