Difference between revisions of "Version management"

From GeopsyWiki
Jump to navigation Jump to search
Line 78: Line 78:
 
   dpclean
 
   dpclean
  
We merge changes made on a release branch to the development trunk.
+
We merge changes made on a devel branch to the testing branch.
  
   cd sesarray-2.1
+
   cd testing
   dpsubdo dpcheckout sesarray-2.0
+
  dpsubcommit
 +
  dpsubpush
 +
  cd admin
 +
  dpcommit
 +
  dppush
 +
  cd ..
 +
 
 +
We start by merging admin directory
 +
 
 +
  cd admin
 +
  dpcheckout devel
 +
  dppull
 +
  dpcheckout testing
 +
  git merge devel
 +
  cd ..
 +
 
 +
Then the rest of the structure
 +
 
 +
   dpsubdo dpcheckout devel
 
   dpsubpull
 
   dpsubpull
   dpsubdo dpcheckout master
+
   dpsubdo dpcheckout testing
   dpsubdo git merge sesarray-2.0
+
   dpsubdo git merge devel
 
 
This part must be revised and enlarged when next merge will happen.
 
  
 
== Creating a new branch ==
 
== Creating a new branch ==

Revision as of 14:16, 12 August 2019

Versions of projects

The distribution archive, is made of a lot individual applications and libraries that have their own version. Branches are either stable, testing or devel. Every day changes on all branches are automatically analyzed. Results are directly available in a browser here.

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.

Report of recent modifications and suggestions for version change is available at http://www.geopsy.org/versions. Projects listed in user, restricted and linux are processed. For the other groups run the report manually:

 dpsubdo -l install dpversionreport

Version reporting is currently linked to compilation factory. It might change in the future to report all projects, including more private ones.

Version model for applications and plugins

  • A: major modifications with drastic changes for the end-user
  • B: minor modifications for the end-user
  • C: minor bug fixes almost invisible for the end-user

Version model for shared libraries

  • A: major modifications of the API: compatibility with old codes is not guaranteed.
  • B: minor modifications of the API: some classes or functions were added, inline functions were modified, arguments were added with default values to keep compatibility with old codes. In other words, old codes can still be compiled without modification but binary compatibility is not guaranteed.
  • C: minor revision: API is not modified and binary compatibility is guaranteed. Classes or functions can still be added but inline status or inline contents cannot be modified. Number of arguments cannot be changed. Class members cannot be modified.

There can be also a release name added after a dash. The most common is '-snapshot-YYMMDD' for unstable development releases. In such case, version is labeled as 0.0.0.

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
 dpsubdo dpversion t

Tagging is mandatory for proper version reporting. Do not tag nor change version before a successful test of the distributed archive.

Version of project list

 cd admin
 dversion s

Eventually, set a snapshot version:

 dpversion S

commit the new versions to the repository:

 dpversion c

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#Tagging

Merging

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

 dpclean

We merge changes made on a devel branch to the testing branch.

 cd testing
 dpsubcommit
 dpsubpush
 cd admin
 dpcommit
 dppush
 cd ..

We start by merging admin directory

 cd admin
 dpcheckout devel
 dppull
 dpcheckout testing
 git merge devel
 cd ..

Then the rest of the structure

 dpsubdo dpcheckout devel
 dpsubpull
 dpsubdo dpcheckout testing
 dpsubdo git merge devel

Creating a new branch

We assume that current master branch is 2.1. We want to move master to 2.2. We re-create a complete development tree.

 mkdir 2.2
 git clone ssh://USERNAME@geopsy.org/home/git/geopsyprojects
 mv geopsyprojects admin
 cp ../2.1/admin/options.sub admin
 # Edit to change destination path
 cp ../2.1/admin/projects.default admin
 dpsubconfig -f
 dpsubdo dpstableh
 dpsubpro
 qmake
 make

After first successful build, remove the 3rd parties from 2.2.pro file to avoid problems with QtCreator

We assume /usr/local/Geopsy.org/2.2/ as the destination path

 export PATH=/usr/local/Geopsy.org/2.2/bin:$PATH

Within the previous master tree

 cd 2.1
 dpsubdo cp admin/version-master admin/version-2.1
 dpsubdo git add admin/version-2.1
 dpsubdo git branch 2.1
 dpsubdo dpcheckout 2.1
 dpsubdo git commit -a -m "New branch 2.1"
 dpsubpush
 cd admin
 cp admin/version-master admin/version-2.1
 git add admin/version-2.1
 git branch 2.1
 dpcheckout 2.1
 dppush

Log to Windows server, Sources server and Mac OS X server

 Add branch 2.2 to option.factory (in BRANCHES)
 Run dpfacsetoptions to create the source tree