Opened 7 years ago

Closed 5 years ago

#46 closed Task (fixed)

Version policy / Roadmap

Reported by: pesei Owned by: pesei
Priority: major Milestone: Long-term tasks
Component: FP other Version:
Keywords: Cc: rstow

Description

(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

Change History (9)

comment:1 Changed 7 years ago by DefaultCC Plugin

  • Cc rstow added

comment:2 Changed 7 years ago by pesei

  • Owner changed from somebody to pesei
  • Status changed from new to accepted

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.

comment:3 Changed 7 years ago by pesei

  • Milestone set to Long-term tasks

comment:4 Changed 7 years ago by 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

comment:5 Changed 7 years ago by 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

comment:6 Changed 7 years ago by 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.

comment:7 follow-up: Changed 7 years ago by pesei

Naming for ECMWF extraction scripts
is also needed

comment:8 in reply to: ↑ 7 Changed 6 years ago by pesei

Replying to pesei:

Naming for ECMWF extraction scripts
is also needed

We have in downloads :

tarball file nameDescription
ecmwf_routines_V21.tar.gzpreprocess 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

comment:9 Changed 5 years ago by pesei

  • Resolution set to fixed
  • Status changed from accepted to closed

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).

Note: See TracTickets for help on using tickets.
hosted by ZAMG