[Cubicweb] CubicWeb numbering scheme and release process

David Douard david.douard at logilab.fr
Wed Jul 22 09:47:25 CEST 2015


Dear all,

While releasing CubicWeb 3.21, we discussed a few shortcomings of our current release process.

The current situation looks like this:

- we release roughly twice a year,

- we do not publish bugfix releases with non-bugfix changesets, but do not really comply
  with semantic versioning either, because 

- when we deprecate an API, we try to keep the backward compatibility code for at least 2 years 
  (often more, exceptionally less, like some deprecations introduced in 3.19 for which 
  compat code was removed in 3.21, but we try very hard not to),

- we officially maintain 2 releases (currently 3.19 and 3.20, soon 3.20 and 3.21 only). 
  It is not prohibited to publish fixes for older releases, but these have to be supported by 
  users or customers who need these fixes,

- the integration process is not very smooth (patches are integrated mostly when we are 
  preparing a release, instead of being merged regularly during the whole 6 month period).

The main shortcomings we have identified are:

- the major version ("3") has become meaningless,

- integrators have a huge number of changesets to review and merge in a short timeframe,

- contributors are pushing patches just before the release because they do not want to wait
  for another 6 months to get a chance to include their bugfixes and features integrated,

- developers who ask themselves "how hard will it be to upgrade my application to a new CubicWeb version?",
  have a hard time figuring out the answer and are not helped by the current versioning scheme.

In order to improve on this situation, we propose to get closer to a continuous process:

- switch to a time-based cycle and release every 3 months (we will freeze the version a month
  before the release date, refuse any patch that is not ready for integration at this date and
  will NOT wait for some new feature that are almost-but-not-quite ready),

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

- always fix bugs for the latest two versions and try to maintain the two that came before,

- cubes are not concerned by these changes.


-- 

David DOUARD		 LOGILAB
Directeur du département Outils & Systèmes

+33 1 45 32 03 12	 david.douard at logilab.fr
+33 1 83 64 25 26	 http://www.logilab.fr/id/david.douard

Formations - http://www.logilab.fr/formations
Développements - http://www.logilab.fr/services
Gestion de connaissances - http://www.cubicweb.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: david_douard.vcf
Type: text/x-vcard
Size: 302 bytes
Desc: not available
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20150722/78102230/attachment-0251.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20150722/78102230/attachment-0251.sig>


More information about the Cubicweb mailing list