[Cubicweb] CubicWeb numbering scheme and release process

Sylvain Thénault sylvain.thenault at logilab.fr
Wed Jul 22 18:06:58 CEST 2015


I'm very fine with all those changes but would like to discuss (quickly) the two
points below:

> - change the numbering to a "year.month" scheme; with 4 releases a year, the next 
>   versions will be something like "15.10", "16.01", "16.04", "16.07" (or similar),
> - commit to keep the backward-compatibility code for at least a year (meaning 4 versions:
>   a deprecation introduced in 15.10 will not be removed before 17.01) and clearly
>   document the important changes and the migration path in the release notes,

The proposed numbering scheme makes it hard to know which release is a major
release or not. Also, we should probably not commit to something else than
maintaining a release for at least one year.

I would propose something like:

* stick to semantic versioning X.Y.Z

* one Y+1 release every 3 months

* may be replaced by a X+1 major releases as needed, which is allowed to
  introduce bw incompatible API (incl. bw compat removal) *but* must be able 
  to migrate database from the previous major release

Sylvain Thénault, LOGILAB, Paris ( - Toulouse (
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

More information about the Cubicweb mailing list