## This file is part of CDS Invenio. ## Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 CERN. ## ## CDS Invenio is free software; you can redistribute it and/or ## modify it under the terms of the GNU General Public License as ## published by the Free Software Foundation; either version 2 of the ## License, or (at your option) any later version. ## ## CDS Invenio is distributed in the hope that it will be useful, but ## WITHOUT ANY WARRANTY; without even the implied warranty of ## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ## General Public License for more details. ## ## You should have received a copy of the GNU General Public License ## along with CDS Invenio; if not, write to the Free Software Foundation, Inc., ## 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. 

1. STABLE RELEASES

CDS Invenio stable releases use the classical major.minor.patchlevel
release version numbering scheme that is commonly used in the
GNU/Linux world and elsewhere.  Each release is labelled by

     major.minor.patchlevel

release version number.  For example, a release version 4.0.1 means:

       4 - 4th major version, i.e. the whole system has been already
           4th times either fully rewritten or at least in its very
           essential components.  The upgrade from one major version
           to another may be rather hard, may require new prerequisite
           technologies, full data dump, reload and reindexing, as
           well as other major configuration adapatations, possibly
           with an important manual intervention.

       0 - 0th minor version, i.e. the first minor release of the 4th
           major rewrite.  (Increments go usually 4.1, 4.2, ... 4.9,
           4.10, 4.11, 4.12, ... until some important rewrite is done,
           e.g. the database philosophy dramatically changes, leading
           to a non-trivial upgrade, and then we have either higher
           4.x in the series or directly 5.0.0.)  The upgrade from one
           minor version to another may be laborious but is relatively
           painless, in that some table changes and data manipulations
           may be necessary but they are somewhat smaller in nature,
           easier to grasp, and possibly done by a fully automated
           script.

       1 - 1st patch level release to 4.0 series, fixing bugs in 4.0.0
           but not adding any substantially new functionality.  That
           is, the only new functionality that is added is that of a
           bug fix nature.  The upgrade from one patch level to
           another is usually very straightforward.

           (Packages often seem to break this last rule, e.g. Linux
           kernel adopting new important functionality (such as
           ReiserFS) within the stable 2.4.x branch.  It can be easily
           seen that it is somewhat subjective to judge what is
           qualitatively more like a minor new functionality and what
           is more like a patch to the existing behaviour.  We have
           tried to distinguish this with respect to whether the table
           structure and/or the technology change require small or
           large upgrade jobs and eventual manual efforts.)

So, if we have a version 4.3.0, a bug fix would mean to release 4.3.1,
some minor new functionality and upgrade would mean to release 4.4.0,
some important database structure rewrite or an imaginary exchange of
Python for Common Lisp would mean to release 5.0.0, etc.

2. DEVELOPMENT RELEASES

The CDS Invenio development releases as well as CVS snapshot tarballs
that are labelled by:

     major.minor.patchlevel.YYYYMMDD

where YYYYMMDD is the date when the development release or the CVS
snapshot tarball was produced.  These releases are not officially
supported and they can change dramatically from one YYYYMMDD to
another.  You can test them, but do not rely on them in production
environment unless you know what you are doing.

- end of file -