Version policy / Roadmap

[pesei]

(from minutes of FpDev Workshop 2012)

The introduction of a version policy is regarded as necessary; a new FLEXPART version should be introduced not more than once a year

[pesei]

Please, first read ​http://en.wikipedia.org/wiki/Software_versioning

Versioning scheme

My first suggestion, as a starting point, and more or less in line with our prevous practice would be

major.minor[.micro][-beta][.rev]

Major would be associated with highly significant changes in functionality, model physics or numerics, including major changes to input and output formats.

Minor would be associated with less significant changes in functionality, model physics or numerics as well as important bug fixes.

Micro would be used for minor bug fixes or practically insignificant other changes.

Furthermore, I suggest to attach either -b or even more explicitly -beta to any version which has not undergone certain rigorous testing and review, which probably still needs to be defined in more detail (cf. ticket:38)

.rev would look like .r14 to denote revision 14 in the SVN. This would only be used for internal purposes, downloads should not carry such revision identifiers.

Tarball naming

As visible in downloads, the naming of the tarballs has been quite inconsistent. I think there is no OS on which FLEXPART would be used that does not support multiple dots in filenames. Thus I suggest to use names such as

flexpart_9.1.tgz or
flexpart_9.2-beta.r14.tgz

Roadmap

Our trac system has a [roadmap/] functionality that will show Milestones (= releases) with their associated tickets. However, this may be too detailed, and it contains no information about the earlier releases. Therefore I suggest to build up a wiki:FpRoadmap containing overview information what is new in which major and minor release, and when they were / will likely be released.

[pesei]

Tarball naming for FpWRF etc

For nonstandard versions, e.g. WRF versions, we should distinguish the main FLEXPART version used as a base, and then a versioning for the WRF derivative.

Jerome's recent tarball [see ​http://flexpart.eu/wiki/FpLimitedareaWrf] could then be named, supposing that FLEXPART 9 is its base (jerome, pls correct me if it is not conforming to the history of the code)

flexpart_wrf_3.1_fpbase_9.tgz

[jbrioude]

Yes, it is based on the latest version of flexpart 9.
The information on what flexpart-wrf is based on is important, but is it critical enough to put it in the name of the tarball?
Maybe instead of putting "fpbase_9" in the name, we can put this information directly on ​http://flexpart.eu/wiki/FpLimitedareaWrf wikipage

[pesei]

Based on comments I received off-line ("information is always useful") I suggest that we keep the fpbase part of th tarball name at least in the official flexpart.eu download list. If people prefer to use a shorter name internally, no problem.

[pesei]

Naming for ECMWF extraction scripts
is also needed

[pesei]

Replying to pesei:

Naming for ECMWF extraction scripts
is also needed

We have in downloads :

tarball file name	Description
ecmwf_routines_V21.tar.gz	preprocess ECWF Version 2.1
ecmwf_routines_V4.tar.gz	preprocess ECWF Version 4
flex_extract_ecgate_V4.1.tar.gz	ECMWF data extraction

Proposed scheme, in accordance with tarball for FLEXPART itself as proposed abov (for the example of Version 5.0):

ecmwf_extraction_5.0.tgz

ECMWF data extraction V5.0

[pesei]

As their have been no more comments, I consider the above suggestions as adopted.
They should be applied to all new tarballs and versions
(for previous ones, may rename tarballs).