Mettre en place un suivi de numéros de version et viser la distribution

[olof29]

depuis le départ de cette aventure, Frontières a maintenant beaucoup évolué.

• ne serait il pas bon que maintenant il y ait une numerotation de versions en rapport avec les evolutions apportées et un suivi de ceux ci ?
• que manque t'il au projet pour en permettre la diffusion dans des distributions ?

[jpcima]

Une manière appropriée de suivre les versions, selon moi :

• appliquer un tag sur les versions finalisées. Il en existe déjà un sur la v0.4, on peut donc continuer sur ce modèle en utilisant les recommandations https://semver.org/

• on peut mettre un script qui récupère le nom du dernier tag à l'aide de git, et générer un fichier tel que Version.h, permettant d'afficher cette version dans le logiciel. Il est à noter que QApplication stocke une propriété applicationVersion.

• je pense qu'il est souhaitable de maintenir une section "Journal des changements" dans le README, qui est ordonné par numéro de version décroissante, + les modifications concernant la version en développement

• une courte documentation du protocole de sortie de version, un pense-bête permettant de s'assurer de ne rien oublier.

[trebmuh]

👍 pour tout ça

[fpesari]

I do not speak French but from what I have gathered, you are talking about using version numbers for releases. If so, I agree. I am packaging Frontieres for openSUSE and a release would be much helpful.

[jpcima]

Yeah, discussion is about setting up a release protocol for new versions, as there isn't currently a release since forking Borderlands.

One important item, before I forget:

• the scene files should save the program version number in them. it will help maintaining compatibility a lot in the future

@fpesari since you mentioned building openSUSE many times, do you have experience with hooking github to OBS for continuous builds?
This project (among others) is going to benefit from git builds to get people helping with the testing, and I'm looking to implement such a thing.

[fpesari]

@fpesari since you mentioned building openSUSE many times, do you have experience with hooking github to OBS for continuous builds?
This project (among others) is going to benefit from git builds to get people helping with the testing, and I'm looking to implement such a thing.

Yes, I am making a git master based package right now. It doesn't work yet because OBS needs some fixes like #91 to publish the package, but it will work as soon as #91 (and similar bugs, if there are) is fixed, more or less.

My package is under the GPLv3 so you can fork it as soon as it's ready (I will post here as soon as it's online, please keep this issue open), but actually, since I contribute to a stable-ish OBS repository (Geekos DAW) we'd prefer to have stable releases instead of checking out from git directly.

[fpesari]

Hi,

our openSUSE Frontierès package on OBS is up and working.

Now it uses the git service to pull from git master, but I'd like to switch to numbered releases in the future, if you decide to adopt them.

Edit: perhaps, you could continue the numbering from Borderlands, even if Frontierès is a separate fork. Just to give it some continuity with the past, since it is an improvement of Borderlands 0.4.

[olof29]

maintenant que frontieres est distribué, il me parait important de mettre en effet en place les numeros de versions, mais pas seulement.
les fichiers readme renvoient à borderlands, et depuis ça a bien evolué.
il serait bon d'y inclure les references du github, et aussi les droits qui ne se limitent plus à ceux de borderlands puisque nous avons ete au moins 4 autres à travailler dessus.
au depart jpcima ajoutait des infos sur les droits quand nous avions participé au travail, depuis un moment, ce n'est plus ajouté. ne serait il pas bon de revoir cette question ?
j'avoue etre pour ma part assez etranger a ces notions, je veux juste faire avancer le logiciel parceque je veux l'utiliser, mais si ça doit servir a d'autres il serait preferable de bien ficeler tout ça.

[jpcima]

@fpesari thank you, I have tried, unfornatunately I was unsucessful in running another build than openSUSE. It said that it doesn't recognize the services.
https://build.opensuse.org/package/show/home:jpcima/frontieres-devel

@olof29 / @trebmuh / @fpesari

copyright headers out of date

For sure yes, I admit not being particularly rigourous when it comes to these, so it will be welcome to make a review. Surely, we are able to automate this from the git log.

finalizing the software

Sure, but prior to that, there's at least a few things that I wish to review.
I think, it is benificial to identify some remaining problems and arrange them into target milestones.
Until we can hit the final release, we can aim for some pre-release with a beta version tag.

To clean up for a release, I think of cleaning small defects which hurt usability or consistency.
For example, I'll list one example which comes to me as a bit striking.

This is the current options dialog.
It doesn't have a correct title set ("Dialog"), and it shows a blank empty tab as soon as opened.

There's some others:

• the right click menu has "Create new cloud", but doesn't show the shortcut "(G)" as shown in numerous other locations
• in the "Cloud parameters" dialog, the shortcuts are lower cased ex. ("(g)") contrary to how it is in other places
• in that same dialog, "Fréq LFO" is labeled as shortcut "(1)" (should be "L")
• in the console, this warning is seen: QMetaObject::connectSlotsByName: No matching signal for on_doubleSpinBox_Midi_Channel_valueChanged(double)

(to list a number of things, but it should be tested for more)

[olof29]

Olinuxx m'a aussi dit que pour pouvoir suivre cette numerotation dans la publication des paquets, il faut qu'un tag de version suive celle ci. il me semble que je n'ai pas la main la dessus.

[jpcima]

C'est exact, tu dois avoir la possibilité de créer un tag dans la copie locale, mais pas la permission de l'envoyer sur origin.
Il faut que ce soit une personne avec les droits du dépôt qui le fasse. (@trebmuh, @r1, moi)

Si tu as acquis une certaine aise avec l'outil git, je pense qu'on peut éventuellement t'accorder l'accès en écriture. Demandons à @trebmuh son avis.

Ça se passe à peu près comme ceci en principe.

git tag -a -v v1.0.0 -m "Ma version 1.0.0"
git push -u origin v1.0.0

[olof29]

Je commence en effet à avoir manipulé git dans pas mal de sens, mais je n'assure pas en être maitre, ceci dit je continue de progresser.
Par contre les recommandations de jpcima :

appliquer un tag sur les versions finalisées. Il en existe déjà un sur la v0.4, on peut donc continuer sur ce modèle en utilisant les recommandations https://semver.org/

ok, ça c'est ce que j'ai suivi dans les numeros de versions dans le fichier version.h

on peut mettre un script qui récupère le nom du dernier tag à l'aide de git, et générer un fichier tel que Version.h, permettant d'afficher cette version dans le logiciel.

ça je ne sais pas faire. pour le moment, le fichier version.h, c'est moi qui le mets a jour manuellement à chaque pr.

Il est à noter que QApplication stocke une propriété applicationVersion.

et ce serait aussi recuperable automatiquement ?

je pense qu'il est souhaitable de maintenir une section "Journal des changements" dans le README, qui est ordonné par numéro de version décroissante, + les modifications concernant la version en développement

ça il va falloir que je m'y mette ... (ce ne serait pas mieux dans un fichier changelog ?

une courte documentation du protocole de sortie de version, un pense-bête permettant de s'assurer de ne rien oublier.

ça serait pas mal en effet. (il y a encore plein de chose que je veux faire dans frontieres, donc ça servirait...)

D'autre part, j'ai travaillé un peu sur l'empaquetage de la version maintenant dans le labo de librazik 3, et en me familiarisant avec cette démarche, j'ai vu que d'autres logiciels stockaient aussi dans github le repertoire /debian avec les fichiers de config des paquets.
serait il judicieux qu'on le fasse aussi ?

[olof29]

ok, j'ai donc maintenant les droits pour publier.
comment est ce qu'on procède ?
est ce que je continue d'attendre tes avis pour passer les, ou est ce que je les passe moi meme quand je les trouve raisonnablement stables ?
pour le versioning, est ce que chaque pr passé amene a publier une nouvelle version ? (logiquement je pense que oui) est ce que cette version fait l'objet d'un tag ou d'une release ?
dois je joindre un changelog ?

[jpcima]

Il est à noter que QApplication stocke une propriété applicationVersion.
et ce serait aussi recuperable automatiquement ?

Rien de nécessairement utile, je notais que tu peux récupérer et stocker cette version à l'aide de QApplication::setApplicationVersion.

ça il va falloir que je m'y mette ... (ce ne serait pas mieux dans un fichier changelog ?

C'est de ça qu'il est question oui.

D'autre part, j'ai travaillé un peu sur l'empaquetage de la version maintenant dans le labo de librazik 3, et en me familiarisant avec cette démarche, j'ai vu que d'autres logiciels stockaient aussi dans github le repertoire /debian avec les fichiers de config des paquets.

Cela, je ne suis pas certain que ce soit une bonne idée. Peut-être que @trebmuh peut donner son avis.

ok, j'ai donc maintenant les droits pour publier.
comment est ce qu'on procède ?

La première étape consiste à publier un tag.
Ensuite empaqueter les binaires et les sources, avec un schéma de nommage de type Frontieres-X.Y.Z.

• Pour les sources : git-archive-all;
• pour les binaires, réempaqueter ce qui provient de la construction automatique.

est ce que je continue d'attendre tes avis pour passer les, ou est ce que je les passe moi meme quand je les trouve raisonnablement stables ?

Peut-être récolter au préalable quelques retours de tests de la communauté LibraZiK.

Pour l'instant @trebmuh est occupé à réaliser LZK3, donc mieux vaut ne pas le solliciter pour produire des paquets test.

Une solution consiste à distribuer nos propres paquets Deb en release continue. (paquet checkinstall)
Je tâcherai de modifier la CI afin de rendre ça possible.

pour le versioning, est ce que chaque pr passé amene a publier une nouvelle version ? (logiquement je pense que oui) est ce que cette version fait l'objet d'un tag ou d'une release ?
dois je joindre un changelog ?

Les PR ne modifient pas la version, mais cela peut être intéressant pour les versions non-finales de présenter le numéro de commit GIT dans la boîte "À propos" par exemple.

On peut lister les éléments de ChangeLog au fur et à mesure des commits, et puis renseigner le numéro de version au moment de la publication.

[jpcima]

Un paquet automatique est disponible. J'ai basculé la CI sur Travis.
https://github.com/linuxmao-org/Frontieres/releases/tag/automatic

[olof29]

ça veut dire qu'a chaque PR passé, il créera automatiquement les paquets, maintenant ?

sinon voici ce que j'ai compris, et applique sur les numeros de versions :
version x.y.z
z change pour des reparations de bugs
y change pour des apports de nouvelles fonctions
x change quand des changements de fonctions rendent incompatible avec la version precedente (sauf passage x=0 API en developpement à 1 API fixée)

c'est bien ça ?

comment la CI automatique recupere t'elle ces numeros de versions, ou les numeros de commit ?

et sinon, pour ce qui est des passages de PR que je peux maintenant faire, dois je aussi attendre des retours avant de les passer ?
(je vois par exemple que sur ma demande de PR #98, tu t'es assigné, cela veut il dire que tu dois tester ça avant que je ne passe le pr ?)

j'ai aussi déjà travaillé avec trebmuh à la version librazik de test qui est maintenant présente dans le testing de librazik3

[jpcima]

ça veut dire qu'a chaque PR passé, il créera automatiquement les paquets, maintenant ?

Oui. Ces paquets ne comptent pas comme release, ils sont là pour faciliter le processus de test.

sinon voici ce que j'ai compris, et applique sur les numeros de versions

Ça peut être défini de cette manière, personnellement cela me convient.

comment la CI automatique recupere t'elle ces numeros de versions, ou les numeros de commit ?

À partir des numéros de tags s'il y en a, ce n'est pas le cas pour l'instant.
C'est un numéro de version constitué du dernier tag et la date du jour, par exemple vX.Y.Z~git20201201.

et sinon, pour ce qui est des passages de PR que je peux maintenant faire, dois je aussi attendre des retours avant de les passer ?

Oui de préférence, mais on peut aussi passer sur un fonctionnement un peu plus flexible.
Comme chez falktx/Carla par exemple.

Cela consiste à diviser le dépôt en branches develop et master.

• master reçoit les fonctionnalités testées et jugées stables;
• develop pour recevoir les PR, que tu aurais la liberté de fusionner toi même. (ce qui n'empêche pas à chacun d'apporter son commentaire sur les PR)

la fusion develop → master serait envisagée suite aux retours de tests.

On peut faire comme ça.

[olof29]

que manque t'il pour pouvoir fusionner les branches et editer une version 1.0 ?
j'ai personnellement fait des tests puisque je me sers de frontieres, mais faut il que le(s) testeur(s) soit d'autres que moi ?