Versionsverwaltung, Releases, Produktionbibliotheken

Hallo,

hier endlich, endlich die Zusammenfassung
unseres Treffens vor x Wochen und meine
Gedanken zum Thema Versionsverwaltung,
Releases und Produktionsbibliotheken.


1. Folgendes Versionierungsschema haben wir
   uns überlegt. Mit ihm kann man anhand der
   Versionsnummer weitgehend Kompatibilitäten
   zwischen Modulen erkennen. Die Notwendigkeit,
   Modulen neue Versionen zu verpassen, wenn
   sich deren Code überhaupt nicht geändert
   hat, entfällt damit.


   Beispiel für Release 11 und DPR-Systemversion 09:

     Devman        11.03
     libabc.so     11.04
     libxyz.so     11.07
                    |  |
                    |  + private, laufende Nr.
                    + Release-Nummer

     libvmedevice  11.09.02           drei Stellen!!!
     ECM              09.01
                    |  |  |
                    |  |  + private, laufende Nr.
                    |  + DPR-Systemversion, VmeDevice/ECM-Kompatibiliät
                    + Release-Nummer

     MX-USRs       11.09.12.08        vier Stellen!!!
     MX-EQMs          09.12.09
                    |  |  |  |
                    |  |  |  + private, laufende Nr.
                    |  |  + Geräte-Software, USR/EQM-Kompatibiliät
                    |  + DPR-Systemversion, VmeDevice/ECM-Kompatibiliät
                    + Release-Nummer


   Auf /opt/acc/cpu (vom PPC aus gesehen) für
   Release 11 und DPR-Systemversion 09:

     library -> /opt/acc/sys/devman/11
     mx.so -> /opt/acc/eqp/mx/mx.so.11.09.12.08

   Auf 'library':

     devman -> devman.ppc.11.03
     libabc.so -> libabc.so.11 -> libabc.so.11.04
     libxyz.so -> libabc.so.11 -> libabc.so.11.07
     libvmedevice.so -> libvmedevice.so.11.09 -> libvmedevice.so.11.09.02

   * Für die libvmedevice.so gibt es eine Sonder-
     behandlung. Die Datei hat eine 3-stellige
     Versionsnummer, im Gegensatz zu allen anderen
     libxxx.so, die nur 2-stellige Versionsnummern
     haben. Geht das mit unseren 'nightly'-Skripts?

   * Alle Versionsnummern sind zwei-ziffrig, also
     'libxyz.so.03.07', nicht 'libxyz.so.3.7'.
     Sie entsprechen genau den Repository-Tags.

   * Keine System-Version (CorbaIfc-Version)
     mehr. Die ist nun in 'CorbaInterface##'
     versteckt. Release 11 hat 'CorbaInterface01'
     (Release 12 nicht notwendigerweise
     'CorbaInterface02').

   * Die zur Zeit gültigen oberen Versionnummern,
     also 1 bzw. 01 für X86 und 9 bzw. 09 für PPC,
     fallen ersatzlos weg.

     Das entsprechende Macro "ACC_ASL_SYSVERSION"
     fällt ebenfalls weg.

     Das Macro "ACC_VME_SYSVERSION" bleibt
     erhalten, wird aber nur noch für Tests
     der Kompatibilität zwischen VmeDevice,
     USRs, ECM (-Lib) und EQMs verwendet.

   * Jede neue Release wird in eigenen Release-
     Directories abgelegt, also in
     '$PROOT/lib/asl/<Release>',
     '[...ppc_6xx]/opt/acc/sys/devman/<Release>'
     usw. Auch hier fällt das 'v01' bzw. 'v09'
     weg.

   * Beachten: Die Gerätemodell-Directories unter
     /opt/acc/eqp haben keine Release-Directories,
     also etwa /opt/acc/eqp/mx/11 gibt es nicht.
     Ist das okay so? Bedenken muss man, dass hier
     auch die EQM-sr-Files liegen, die nicht
     release-abhängig sind. Außerdem haben die
     USRs die Release-Nummer im Dateinamen.

   * Die Property VERSION der USRs liefert nach
     wie vor "MX  09.12.08".

   * Für den Devman sollten wir eine Property
     LIBVERS erfinden, analog zu USRVERS, die
     die Versionen der eingebunden Libs zurück
     liefert. Beim Generieren muss einer Lib
     also ihr Versionsstring mitgegeben werden.
     Außerdem muss jede Lib eine Methode bereit
     stellen, um ihre Version abfragen zu
     können.

     Das sollte inklusive der eingebundenen
     USRs geschehen! Sonst kriegt man die
     Release-Nummer (die ganz linke) der USRs
     nie heraus.

     Wie das genau geht, muss noch überlegt
     werden.

   Damit könnte man, wie bisher schon, die
   Kompatibilität zwischen Devman, ECM, USRs
   und EQMs an den Versionsnummern erkennen.


2. Generieren und Releasen von Devman und
   seinen Bibliotheken.

   Wie weit wir da sind, ist mir im Moment
   nicht komplett klar. Deshalb im Anschluss
   erst mal ein paar grundsätzliche Bemerkungen.

   * Im Grunde sollte _nichts_ händisch
     gemacht werden müssen. Alles, was man
     braucht für eine Generierung oder ein
     Release, sollte in passenden Skripten
     stecken. Nur dann kann man nichts
     mehr (oder nicht mehr viel) falsch
     machen oder übersehen.

   * Ein bestimmtes Release muss später
     immer wieder exakt nachgebaut werden
     können.

   * Mir scheint, dass der Übergang zwischen
     Generierung und Release fließend ist,
     zumindest im Moment, wo die generierten
     Dateien direkt auf dem Produktions-
     Directory abgelegt werden, und nicht mehr
     irgendwo privat, um sie erst mit einem
     Release auf das Produktions-Directory
     zu kopieren.

     Wenn das so bleibt, muss auch schon bei
     der Generierung (Makefile.*) ein Logfile
     geschrieben werden - und darin alle
     generierten Dateien aufgeführt werden.
     Das ist insbesondere im Falle des Nach-
     Releases eines einzelnen Moduls wichtig.
     Beispiel: Werden die generierten Dateien
     auf $PROOT/lib/asl/11 abgelegt, dann muss
     dort auch 2008-09-10.log geschrieben
     werden.

     Genau genommen müssen bei der Generierung
     _zwei_ Logfiles geschrieben werden: Eines
     für den ASL-Devman auf $PROOT/lib/asl/11
     und eines für den PPC-Devman auf
     [...eldk/ppc_6xx]/opt/acc/sys/devman/11.

   * Ist die Generierung (Makefile.nightly)
     bereits Teil des Release-Prozesses,
     dann dürfen nur Module generiert werden,
     deren Versionsnummern einem Tag im
     Repository entsprechen! Das muss vom
     Skript überprüft werden!

   * Wie macht man ein Nach-Release eines
     einzelnen Moduls, wenn die Generierung
     schon Teil des Release-Prozesses ist?
     Einfach mit 'generiere <modul>'?

     Dem Scirpt sollte es jedenfalls nicht
     möglich sein, eine Datei libxyz.01.02
     auf einer Release-Directory anzulegen,
     wenn es diese dort schon gibt! Die neue
     Datei muss eine höhere Versionnummer
     haben, also mindestens libxyz.01.03!

     Am Besten handhabbar wird es wahrschein-
     lich sein, Nach-Releases komplett zu
     generieren und sie in eigenen Directories
     abzulegen, also z.B. $PROOT/lib/asl/11,
     $PROOT/lib/asl/11a, $PROOT/lib/asl/11b
     usw.

   * Eine komplette Produktionsumgebung wird
     es zunächst wohl nur auf den PPC-GuPs
     geben. Auf den ASL-Rechnern sind wir
     nicht weit davon entfernt. Wie sieht
     es aber mit mBox und besonders mit
     Windows (anderes Betriebssystem!) aus?

   * Wir sollten /usr/local/lib _nicht_ mehr
     als allgemeine Test-Directory benutzen,
     da es wohl eine übliche Linux-Directory
     ist - wo u.a. die OmniOrb-Libs liegen -,
     die man nicht so verschmutzen sollte.
     Besser wäre z.B. /usr/local/scratch/lib,
     /usr/local/scratch/eqp oder so.


3. Was gibt es Besonderes zu beachten beim
   Release des Nameservers und des UfcServers?

   Man sollte sie getrennt voneinander und
   getrennt vom Devman generieren und releasen.


4. Im Repository wird auch '<eq-model>-usrs.xml'
   gespeichert und getagged. Daraus generierte
   Dateien, z.B. '<eq-model>-<property>-adapter.hh,
   werden nicht gespeichert. Will man später eine
   alte Release noch mal generieren, braucht man
   dazu das damals gültige 'usrgen'. Es muss also
   (zumindest) auch das Projekt 'uti/xml' mit jeder
   Release getagged und mit 'reldevman' released
   werden!


5. Gilt das unter 4 Gesagte im Prinzip auch für
   'uti/mk'? Dort liegt Makefile.nightly und Co.


7. Was ist mit Python? Dessen Nameservice-Modul
   braucht auch gewisse so-Bibliotheken, die im
   Moment von '/usr/local/acc/develop/lib/asl/v01'
   genommen werden. Auf '/opt/acc/sys/devman/v09/07/'
   liegen die Bibliotheken zwar auch, haben aber
   zum Teil andere Versionsnummern.


8. Nebenbei zur Kenntnis nehmen sollte man
   die Linux-übliche Bezeichnung der Versionen
   von 'shared libraries':

     libfoo.1.2.3
       1 - major version number
       2 - minor version number
       3 - release

   Hier ist die Release die unwesentlichste
   Nummer. In unserem System ist's (eher)
   umgekehrt.



A) Beispiel: Erzeugen der Release 11 eines Devman

     $ gendevman 11                    # [1]
     $ reldevman 11                    # [2]
     $ reldevman --host=kp1cg02 11     # [3]
     Warning: Incompatible links to USRs exist on host directory:
       ec.so -> /opt/acc/eqp/ec/ec.so.10.09.08.01
       mx.so -> /opt/acc/eqp/mx/mx.so.10.09.12.07

   [1] Generieren mit neuesten Release 11-Dateien aus SVN
   [2] Release Step 1: 'current'-Links setzen
   [3] Release Step 2: 'library'-Link für einen GuP setzen inkl.
       Warnung, wenn es inkompatible USR-Links gibt.

   Dasselbe Schema gilt z.B. für eine Release 11a, wobei in SVN
   usw. natürlich nach Release-Nummer '11' geguckt werden muss.



B) Beispiel: Nachgenerieren eines Projektes einer bereits
   bestehenden Release 11a:

     $ gendevman --project=accdata --tag=11.00.01 11a   # [1]

   [1] Die angegebene Release-Nummer muss im Tag enthalten
       sein (wobei das 'a' in '11a' natürlich ignoriert
       wird).

       Eine bestehende Datei im Release 11-Directory darf
       nicht überschrieben werden. Die neu generierte
       Datei muss eine höhere Versionsnummer haben.



C) Beispiel: Erzeugen einer bereits bestehenden Release 11
   mit der Angabe einer Tag-Datei:

     $ gendevman --file=<file> 11      # [1]
     Release 11 already exists!
     Continue anyway? [N] Y
     Links to release 11 production files will be overwritten!
     Really continue? [N] Y
     Error: File 'accdata.so.11.00.01' already exists

   [1] Generieren mit den in <file> angegebenen SVN-Projekt-Tags,
       wobei <file> so aussehen könnte:

         accdata    11.00.01
         accdevice  11.03.00
         ...

       Die angegebene Release-Nummer muss in den Tags enthalten
       sein.

       Bestehende Dateien im Release 11-Directory dürfen
       nicht überschrieben werden. Die neu generierten
       Dateien müssen höhere Versionsnummern (Tags) haben.



D) Was wird gelogged?

   a) gendevman:
      - Als Quelle werden die zu generierenden Projekte
        und deren SVN-Tags angegeben.
      - Als Ziel wird immer der komplette Inhalt der
        Release-Directory angegeben.
   b) reldevman:
      Für beide Release-Steps werden die jeweils neu
      gesetzten Links komplett angegeben.



E) Beispiel Log-Einträge

--------------------
hechler  17. September 2008  10:35:51 CET
  Generate Devman
    Sources:
      accdata 11.00.01
      accdevice 11.03.00
      ...
    Targets:
      -rw-rw-r--  1 hechler    18 29.Aug.08 11:21:20 /usr/local/acc/eldk/
          ppc_82xx/opt/acc/sys/devman/11/libaccdata.so -> libaccdata.so.11
      -rw-rw-r--  1 hechler    10 29.Aug.08 11:21:20 /usr/local/acc/eldk/
          ppc_82xx/opt/acc/sys/devman/11/libaccdata.so.11 -> libaccdata.so.11.0
      -rw-rw-r--  1 hechler  1.2M 29.Aug.08 11:21:20 /usr/local/acc/eldk/
          ppc_82xx/opt/acc/sys/devman/11/libaccdata.so.11.0
      ...
--------------------

--------------------
hechler  17. September 2008  10:39:14 CET
  Release Devman
    /usr/local/acc/eldk/ppc_6xx/opt/acc/sys/devman/current -> 11
    /usr/local/acc/production/lib/asl/current -> 11
    /usr/local/acc/production/include/asl/current -> 11
    /usr/local/acc/production/include/vme/current -> 11
    /usr/local/acc/production/python/current -> 11
--------------------

--------------------
hechler  17. September 2008  10:40:43 CET
  Release Devman for KP1CG02
    [/usr/local/acc/eldk/kp1cg02]/opt/acc/cpu/library -> /opt/acc/sys/devman/11
--------------------

Gruß
L.