[Cubicweb] CW app distribution with a not brand new cw version
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
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.
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
- 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