EOLE

h1. Numérotation pour EOLE 2.4

h2. Introduction

La mise en place du nouveau système de build permet de choisir la façon dont les paquets sont numérotés.

h2. Numérotation indépendante des paquets

La branche @master@ contenant le code d’une application externe sera taguée avec le numéro de version de l’application.

Par exemple, pour project:tiramisu version @0.1@:

<pre>

# First upstream

user:~/src/eole/tiramisu (master)$ git tag -s -m "First development release" release/0.1

user:~/src/eole/tiramisu (master)$ git push origin release/0.1

# First Package

user:~/src/eole/tiramisu (master)$ git checkout -b dist/ubuntu/precise/master

user:~/src/eole/tiramisu (dist/ubuntu/precise/master)$ <ADD PACKAGING UNDER debian/>

user:~/src/eole/tiramisu (dist/ubuntu/precise/master)$ git commit -m "Fist package"

# New upstream

user:~/src/eole/tiramisu (dist/ubuntu/precise/master)$ git checkout master

user:~/src/eole/tiramisu (master)$ $EDITOR <some file>

user:~/src/eole/tiramisu (master)$ git add <some file>

user:~/src/eole/tiramisu (master)$ git commit -m "Update some file"

user:~/src/eole/tiramisu (master)$ git tag -s -m "New development version" release/0.2

user:~/src/eole/tiramisu (master)$ git push origin release/0.2

# New package

user:~/src/eole/tiramisu (master)$ git checkout -b dist/ubuntu/precise/master

user:~/src/eole/tiramisu (dist/ubuntu/precise/master)$ git merge -m "New upstream release" release/0.2

</pre>

Cela produira des paquets numérotés:

* @0.1-1@: premier paquet de la première version

* @0.1-2@: second paquet de la première version qui ne corrige que du packaging ou intègre  des patches pour @upstream@ dans @debian/patches/@

* @0.2-1@: premier paquet de la seconde version

* @0.2-2@: second paquet de la seconde version qui ne corrige que du packaging ou intègre  des patches pour @upstream@ dans @debian/patches/@

h2. Numérotation par version de distribution EOLE

Les paquets sont numérotés en fonction de la distribution EOLE, par exemple, pour EOLE 2.4 : @2.4-<version>@

<pre>

user:~/src/project (master)~$ git describe --abbrev=0 --match=release/*

release/2.4

# La branche 2.4 passe en mode support afin de commencer la 2.5

user:~/src/project (master)~$ git branch 2.4 master

# On commence la version 2.5, cela nécessite au minimum un commit qui n’est pas sur la branche 2.4

user:~/src/project (master)~$ <UN NOUVEAU COMMIT SUR MASTER>

user:~/src/project (master)~$ git tag -s -m "Naissance de EOLE 2.5" release/2.5

# On vérifie

user:~/src/project (master)~$ git describe --abbrev=0 --match=release/*

release/2.5

user:~/src/project (master)~$ git checkout 2.4

user:~/src/project (2.4)~$ git describe --abbrev=0 --match=release/*

release/2.4

</pre>

Cette numérotation est celle utilisé pour la version 2.3 (qui était imposé à tous les paquets) :

* On ne versionne pas la branche master, sauf une fois lors de la mise en place d’une nouvelle distribution ;

* Les paquets Debian doivent être au format *@3.0 (natif)@* ;

* Lorsque deux distributions sont maintenues en parallèle, on n’utilise que du cherry-picking entre les branches : l’utilisation de la commande @merge@, dans le mauvais sens, apporterait un nouveau tag et donc une nouvelle numérotation :

<pre>

user:~/src/project (master)~$ git describe --abbrev=0 --match=release/*

release/2.4

user:~/src/project (master)~$ git branch 2.4 master

user:~/src/project (master)~$ <UN NOUVEAU COMMIT SUR MASTER>

user:~/src/project (master)~$ git tag -s -m "Naissance de EOLE 2.5" release/2.5

user:~/src/project (master)~$ git describe --abbrev=0 --match=release/*

release/2.5

user:~/src/project (master)~$ git checkout 2.4

user:~/src/project (2.4)~$ git describe --abbrev=0 --match=release/*

release/2.4

user:~/src/project (2.4)~$ git merge master

user:~/src/project (2.4)~$ git describe --abbrev=0 --match=release/*

release/2.5

</pre>

Cette méthode de numérotation pourrait permettre de numéroter les paquets en fonction des "release redmine":http://dev-eole.ac-dijon.fr/projects/modules-eole/roadmap, il suffirait de créer un nouveau tag sur la branche master avec la version EOLE:

<pre>

user:~/src/project (master)~$ git describe --abbrev=0 --match=release/*

release/2.5

# On commence une nouvelle RC

user:~/src/project (master)~$ git checkout -b rc/2.5.1

# On corrige tous les bugs

user:~/src/project (rc/2.5.1)~$ $EDITOR source_file

user:~/src/project (rc/2.5.1)~$ git add source_file

user:~/src/project (rc/2.5.1)~$ git commit

[...]

# On tag la nouvelle version

user:~/src/project (rc/2.5.1)~$ git tag -s -m "Naissance de EOLE 2.5.1" release/2.5.1

# On intègre à la branche master

user:~/src/project (rc/2.5.1)~$ git checkout master

user:~/src/project (master)~$ git merge release/2.5.1

</pre>

Cela est configurable par [[EoleDebianPackaging24#Il-est-possible-de-modifier-les-sources-dans-le-packaging-ou-il-n’y-a-pas-de-sources-upstream|branche de packaging]].

h2. Extraction des versions depuis les tags.

Il est possible de configurer le format des tags upstream afin d’en extraire un numéro de version, la configuration par défaut de l’utilisateur « @buildd@ » qui consrtuit les paquets source est la suivante :

<pre>

# ~/.gbp.conf

# Configuration file for git-buildpackage and friends

[DEFAULT]

# Where I track upstream

upstream-branch = master

# Branch I use to build package

debian-branch = debian/build

# the default tag formats used:

upstream-tag = release/%(version)s

debian-tag = debian/%(version)s

# Look for a tag matching the upstream version when creating an orig.tar.gz tarball

upstream-tree = tag

# Build only source package

builder = dpkg-buildpackage -nc -d -sa -S -kbuildd@listeseole.ac-dijon.fr

# Upload to reprepro which spool binary builds to rebuildd

postbuild = dput eole $GBP_CHANGES_FILE

</pre>

Il est possible d’écraser ces "paramètres":http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.gbp.conf.html par branche de packaging en créant un fichier @debian/gbp.conf@.

Par exemple, dans le cadre de paquet [[EoleDebianPackaging24#Il-est-possible-de-modifier-les-sources-dans-le-packaging-ou-il-n’y-a-pas-de-sources-upstream|natif]], on peut vouloir forcer l’extraction du fichier @orig.tar.gz@ depuis la branche de packaging :

<pre>

# Per debian package configuration

# It is just used to override defaults upstream tag format

[DEFAULT]

# specific tag format

upstream-tag = upstream/%(version)s

# Extract orig.tar.gz from a branch

upstream-tree = branch

# Force the use of the same branch

# The orig.tar.gz will contain the packaging which is valid only for native package

upstream-branch = mycustom-build-branch

debian-branch = mycustom-build-branch

</pre>