Difference between revisions of "Version management"

From GeopsyWiki
Jump to navigation Jump to search
Line 36: Line 36:
  
 
Do not tag directly before successful testing of the distributed archive.
 
Do not tag directly before successful testing of the distributed archive.
 
== Release production ==
 
 
=== Quick pack testing ===
 
 
Once versions are committed but not tagged for individual packets, increase version for distribution archive. This can be done in any checked out source tree (with the appropriate branch of course)
 
 
  cd sesarray
 
  dpversion s
 
  # Current version=2.0.3
 
  dpversion C
 
  # Current version=2.0.3
 
  # Final version=2.0.4
 
  dpversion c
 
 
On the server, start quicpack-A_B with A_B being the branch number:
 
 
  cd factory
 
  ./quickpack-2_0
 
 
or if you don't want to keep a terminal open:
 
 
  cd factory
 
  rm nohup.out
 
  nohup ./quickpack-2_0 &
 
  exit
 
 
Meanwhile you can update source trees under Mac OS X and Windows and start compilation. Make the distribution executable for these platforms (.exe or .dmg) and test it quickly (e.g. geopsy recognizes its plugins).
 
 
Start automatic validation tests (takes at least 30 minutes). Absolute file path is required (to change in future?).
 
 
  rm nohup.out
 
  nohup ../testing/test /home/sesarray/factory/sandbox-2_0/sesarray/dist/sesarray-src-2.0.4.tar.gz &
 
  exit
 
 
If tests fail, sources can still be modified. Commit changes. If only a few packets were touched, keep the list and increase versions if necessary. If unsure, re-run complete version report. [[Manual version checks]]
 
 
Otherwise, proceed with definitive archive:
 
 
  cd factory
 
  rm nohup.out
 
  nohup ./pack-2_0 &
 
  exit
 
 
  cd factory
 
  rm nohup.out
 
  nohup ./publish-2_0 &
 

Revision as of 14:04, 23 October 2008

Sesarray, the distribution archive, is made of a lot individual applications and libraries that have their own version. Version branches are the same for all items. It is defined at the Sesarray level. Every day changes on all branches are automatically analyzed. Results are directly available in a browser.

Modifications of source code is characterized by its level (script dpversionreport):

  • Level 3: modification of object interface (.h files)
  • Level 2: modification of object implementation (.cpp files)
  • Level 1: currently not used
  • Level 0: no modification

Version numbers are made of three parts: A.B.C

  • A: major modification with drastic changes for the end-user
  • B: major internal modification which breaks binary compatibility (API changed)
  • C: minor bug fixes which ensure binary compatibility (API unchanged). Some functions can be added to object interfaces but existing function definitions are never removed nor modified.

There can be also a release name added after a dash. The most common is '-snapshot-YYMMDD' for unstable development releases. Before producing a snapshot release, versions of individual packets must be increased and committed (not tagged!) according to dpversionreport results.

The summary is an executable bash script that can be used to increment versions of individual applications and libraries. For each modification level, a version increment is labeled B (level 3) or C (level 2). Level 3 may be subject to discussion in case of minor modification of a header file. Modifications on the current stable branch cannot be other that C.

 ######################### geopsy/geopsycore #########################
 OLD_DIR=$(pwd)
 cd gptools/gpsort
 dpversion C
 cd $OLD_DIR

Once this is done for all packets, you can commit the new versions to the repository:

 dpsubdo dpversion c

Do not tag directly before successful testing of the distributed archive.