Java et la gestion des versions d'un projet

Version imprimable

23/01/2016, 13h37
Compassio

Java et la gestion des versions d'un projet

Bonjour.
Etant étudiant à la fac, je vais attaquer mon premier projet java. J'aimerai être capable de versionner mon projet tout au long de cette évolution. Voici déjà mon idée pour la numérotation, je pense adopter un système en x.y.z

x : Le numéro de version majeur, il change uniquement lorsque je fais de grosses modifications, qui peuvent casser la rétro-compatibilité avec les autres versions.
y : Le numéro de version mineur, il change lorsque j'ajoute de nouvelles fonctionnalités au programme, que je supprime des choses où que je corrige des bugs importants.
y : Le numéro de release, il change quand je corrige des petits bugs ou que je fais de très légère modifcations.

Que pensez-vous de ce système ?

Une deuxième chose, j'ai récemment découvert git. Je n'arrive pas à comprendre comment je vais pouvoir l'utiliser pour versionner mon projet, est-ce qu'a chaque commit je vais devoir changer mon numéro de version, comment vais-je devoir procéder si je veux avoir toutes les versions de mon projet sur github ? J'ai du mal à comprendre comment coupler mon versionning avec l'utilisation de git. Merci à vous
23/01/2016, 14h05
tchize_

en général non, on ne fait pas un numéro de version sur chaque commit, mais un numéro de version sur chaque release qu'on fournis à l'extérieur. Le reste, c'est juste des snapshots.

Typiquement tu va avoir la version x.y.z-SNAPSHOT (ou rc, ou buidd123456 peu importe) sur laquelle tu fais tout ton travail, et quand il faut livrer quelque chose ça deviendra la version x.y.z. Quand à la version sur ton git, elle passera à x.y.(z+1)-SNAPSHOT par exemple.

Bien que je comprenne la démarche de vouloir te faire au versionning, un projet scolaire n'aura en général qu'une seule version, la version 1.0 qui est ce que tu livre à ton prof.

Github n'est pas vraiment là pour gérer tes numéros de version, il est là pour gérer l'historique de tes fichiers. Pour tes numéros de version, je dirais vas y lance toi essaie et vois ce que chaque méthode apporte.
23/01/2016, 14h14
Compassio

Salut et merci pour ta réponse :)

Si je comprends bien, je ne toucherai pas à mon numéro de version lorsque je ferai des commits, je le changerai uniquement lorsque je rend disponnible une nouvelle version de mon programme ?
Est-ce que tu as un systèe/méthode à me conseiller pour organiser chacunes de mes versions, car j'aimerai toutes les conserver. Merci
23/01/2016, 14h25
tchize_

en général on marque les numéros de version dans le repository (github / autre) en taggant les versions du code source qui ont servis à créer la version X. Ainsi, si on a besoin de travailler à partir de cette version X on repart de ce tag, si on a besoin de reconstruire X on le fait à partir de ce tag aussi.

Pour ce qui est du stockage du binaire, tout dépends de comment tu travaille. Maven travaille avec un repository où l'on publie les snapshots et les release, pour qu'elles soient conservées et reste accessible aux projets qui en ont besoin. Tu peux aussi simplement mettre chaque version que tu release dans un dossier public, etc. Toutes les options existent, et je ne pense pas qu'il en existe une meilleure que d'autre. L'important est toujours de marquer dans ton GIT que tu fais une release en taggant le code servant à construire cette release. Le plus souvent quand on a besoin d'une ancienne release, c'est pour créer un bug fix donc la partie tagging est importante.

Note que si ton projet est sous ANT tu peux ajouter qq directives dans ton build.xml pour auto-incrementer la version et la date du build sur à chaque compilations sur le serveur d'intégration (inutile de le faire sur les postes dev bien sur).

Quelques chose de similaire à :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
    <target name="-post-compile">
        <propertyfile file="${src.dir}/mon/projet/version.properties"  comment="Build Number for ANT. Do not edit!">
            <!-- This will initialize the entire file content if needed. -->
            <entry key="version.major" type="int"  default="0" />
            <entry key="version.minor" type="int" default="0" />
            <entry key="version.release" type="int" default="1" />
            <entry key="version.codename" type="string" default="" />
            <entry key="version.date" type="date" default="${timestamp}"/>
            <!-- Update relevant values -and initialize them if needed. -->
            <entry key="build.number" type="int" operation="+" default="1" />
            <entry key="build.date" type="date" operation="=" value="${timestamp}" default="${timestamp}"/>
        </propertyfile>
        <!-- Recopy modified file in the binaries folder. -->
        <copy  file="${src.dir}/mon/projet/version.properties" todir="${build.dir}/compiled/mon/projet/"/>
    </target>
    <target name="-pre-jar">
        <propertyfile file="${src.dir}/mon/projet/version.properties"  comment="Build Number for ANT. Do not edit!">
            <!-- Update relevant values -and initialize them if needed. -->
            <entry key="version.release" type="int" operation="+" default="0"/>
            <entry key="version.date" type="date" operation="=" value="${timestamp}" default="${timestamp}"/>
        </propertyfile>
        <!-- Recopy modified file in the binaries folder. -->
        <copy  file="${src.dir}/mon/projet/version.properties" todir="${build.dir}/compiled/mon/projet/"/>
    </target>

Ce qui permet après d'ouvrir et de parser le fichier version.properties (qui sera inclus dans le JAR) pour afficher les valeur et dates dans l'UI ou sur la ligne de commande.

Ici outre la version et la date du build lors de la compilation, la version et la date de release sont aussi modifiée lors du packaging en JAR (dans les dernières versions de NetBeans ces deux opérations ont généralement lieu à chaque compilation alors qu'auparavant le JAR n'était pas forcément créé à chaque compilation du projet).