Difference between revisions of "Version management"

From GeopsyWiki
Jump to navigation Jump to search
Line 55: Line 55:
 
   dpclean
 
   dpclean
  
We merge changes made on a release branch to the development trunk. We assume that branches were previously merged after release sesarray-2_0_3 (properly tagged as specifed at [[Release production#Pack and publish]]).
+
We merge changes made on a release branch to the development trunk.
  
 
   cd sesarray-2.1
 
   cd sesarray-2.1
   dpsubdo cvs update -j sesarray-2_0_3 -j sesarray-2_0_1-branch -I version
+
   dpsubdo dpcheckout sesarray-2.0
 +
  dpsubpull
 +
  dpsubdo dpcheckout master
 +
  dpsubdo git merge sesarray-2.0
  
'admin/version' cannot be merged. It is always different for the two branches. 'sesarray-2_0_1-branch' is the branch tag for branch sesarray-2_0. For next branches better naming must be used: 'sesarray-2_1-branch'
+
This part must be revised and enlarge when next merge will happen.
 
 
To list all conflicts:
 
 
 
  find . -name ".#*"
 
 
 
Resolve all conflicts if any and compile all packets. When successful and before adding new code, automatically commit all merged codes:
 
 
 
  vi admin/autocommit.bash
 
 
 
  echo "Automatic commit"
 
  if ! cvs commit -m "Merge with branch 2.0.4"; then
 
    exit 2
 
  fi
 
 
 
  dpsubcommit auto
 
 
 
Or
 
 
 
  dpsubdo cvs commit -m "Merge with branch 2.0.4"
 

Revision as of 13:24, 20 May 2009

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.

Snapshots

Set snapshot date to all packets (do this before ./quickpack on the server):

 dpsubdo dpversion S

Commit version change:

 dpsubdo dpversion c

Release production#Quick pack and testing

Merging

First remove all temporary files (especially those generated by previous conflicts):

 dpclean

We merge changes made on a release branch to the development trunk.

 cd sesarray-2.1
 dpsubdo dpcheckout sesarray-2.0
 dpsubpull
 dpsubdo dpcheckout master
 dpsubdo git merge sesarray-2.0

This part must be revised and enlarge when next merge will happen.