How to assign version numbers in CWB, CWB-Perl, and CQPweb

Plan for versions: the road ahead

• Version numbering has hitherto been a bit haphazard
• CWB < v3.0 basically represents work done at IMS Stuttgart
  • (plus some betas for subsequent work)
• CWB-Perl version numbering basically indicates what version of the core CWB it is intended to be compatible with
• CQPweb originally had entirely separate version numbering (with only major and minor distinguished)
  • ... but then switched (in July 2011) to the same system as the CWB-Perl

Clearly all this is confusing. So, we have put in place the following policies for subsequent version numbers.

Version numbers for the core CWB

• All version numbers will be of the form x.y.z
• Major public releases of the core CWB will be 3.0.z, 4.0.z, etc.
  • In these releases, the z indicates the maintenance/bugfix release version
• Major releases are allowed to break backwards compatibility, both of library APIs and of user interface.
• There may be intermediate stable public versions, which will not break compatibility (or will do so in a trivial way)
  • These will have the numbers 3.5.z, 4.5.z, etc.
• Any other minor release number represents an unstable beta.
  • Users who want to take advantage of the latest improvements are encouraged to use these intermediate releases.
  • Minor release numbers x.4.z and x.9.z are reserved for betas working up to a new release (stable or backwards-incompatible).
  • Other minor release numbers will not be used by the core CWB. They are reserved for the user-interface components.

Version numbers for CWB-Perl and CQPweb

• All version numbers will follow the same general format as the core CWB.
• All versions of CWB-Perl and CQPweb will have the same major number as the version of the core that they are compatible with.
  • Minor numbers x.0 to x.3 denote compatibility with the stable version x.0 of the core
  • Minor numbers x.5 to x.8 denote compatibility with the stable version x.5 of the core
  • Minor numbers x.4 or x.9, if used, denote compatibiltiy with the upcoming stable version x.5 or (x+1).0 of the core
• An increment in the minor number (say, from 3.5 to 3.6) indicates some major change in the user interface
  • Such a change may possibly break backward-compatibility in the front end, without changing how compatibility with the core works
• An increment in the maintenance/bugfix number represents a smaller change that does not majorly affect the user interface.

Additional caveats for CQPweb

• Increments in CQPweb's capabilities will normally be indicated by an increment in the bugfix (z) number
  • Upgrading from x.y.z to x.y.(z+1) will require updating the code files, and may require manual changes to the database
  • Upgrading from x.y.z to x.y.(z+1):
    • will not require reinstalling the CQPweb system
    • will not require reindexing any corpora (although old corpora may not be able to access new features)
    • will not change the format of any configuration files
    • will not require user accounts to be re-created
  • Upgrading from x.y.z to x.(y+1).0 may require one or more of the above changes, however.