Homec4science
Diffusion invenio-infoscience (maint-2.0) Browse

R3600/modules/webhelp/web/hacking/release-numbering.webdoc
51bfbcb9fa42maint-2.0

Last Change
Raw File

release-numbering.webdoc
View Options

## 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.
<!-- WebDoc-Page-Title: Release Numbering Scheme -->
<!-- WebDoc-Page-Navtrail: <a class="navtrail" href="<CFG_SITE_URL>/help/hacking">Hacking CDS Invenio</a> -->
<!-- WebDoc-Page-Revision: $Id$ -->
<pre>
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 -
</pre>
c4science · Help