Finalisation Rdd v3.0

[nfaugout-lucca]

Est-ce que vous pouvez mettre ici ce que vous aimeriez ajouter dans la v3.0 pour qu'on la finalise ? Et qu'on crée une branche 3.0 pour qu'on puisse ensuite commencer à merger des trucs sur master pour la 3.1

Pour ma part, la PR sur IQuery peut aller dans la 3.1.

Je n'ai rien à ajouter dans la v3.0.

[Poltuu]

Je voulais faire ce genre de chose en effet. Il faut une liste exhaustive des choses à faire, sans doute s'inpirer de ce que font les grands projets pour avoir une idée ? mais sans doute:

• release notes
• est-ce que l'on veut crér de la doc en même temps du style getting started ?
• modifier futur release en v3 dans le changelog.md
• une fois la v3 sortie, mettre à jour lucca.core.rights.integrations.Rdd
• s'assurer que tous les documents et autres font référence à "v3.0.0"

[nfaugout-lucca]

@Poltuu j'en déduis que tu n'as plus de PR à passer sur la v3.0 ?

[Poltuu]

yes, plus rien de mon côté

[rducom]

J'aimerai rajouter les 3 points suivants en v3:

• Parsing des fields via StringSegment
• Exposition des types sur les controlleurs (swagger)
• Switch to newtonsoft.json en mode natif (query.split)

[nfaugout-lucca]

OK, dans ce cas est-ce qu'on peut créer une branche v3.0-rc ou un truc du genre, pour pouvoir commencer à merger des PR sur master en vue de la 3.1 ?

[Poltuu]

le tout que tu proposes est trop gros je pense @rducom:

• Parsing des fields via StringSegment : ok, c'est faisable, puisqu'il faut juste supprimer des trucs en s'appuyer plus ou moins sur le TreeParser existant. Mais, je pense que la disparition de certaines api, notamment de celle prenant une expression (qui devront dès lors prendre un string) pourrait donner lieu à des débats qui pourraient durer
• swagger : si tu parles de rajouter des attributs [Produces] etc ok, c pas trop long. Mais moi j'ai eu des mauvaises surprises avec Produces par exemple, qui n'est pas utilisable sur des retours génériques
• switch sur newtonsoft : perso, j'ai du mal à croire que ce soit simplement possible, mais je demande à voir. En tout cas, ça va prendre facile une semaine en fix, et plein de breaking changes, je préférerai que ça passe dans la v suivante

Je suis aussi de l'avis de nico qu'on tient une bonne version en l'état, et qu'on peut s'en tenir là

[nfaugout-lucca]

Oui, et rien n'empêche de faire des pre-release de la 3.1 sous forme de preview comme on a fait pour la 3.0

[rducom]

Oui rien n'empêche de faire une stable maintenant. Par contre vu les breaking changes sur la prochaine, ce sera une 4.0 pas une 3.1. Perso j'ai aucun pb avec ça mais est-ce que ça vous conviens ?

[nfaugout-lucca]

On peut partir sur une 3.1 et si on voit qu'il y a trop de breaking changes la convertir en 4.0, de toute façon le numéro on le met qu'à la fin non ?

Par ex si c'est "juste" un refacto de la sérialisation, je voterais pour une 3.1, mais si c'est des trucs très structurants comme le fait de ne plus pouvoir avoir des sous ressources (fields récursif) par ex, là ce serait une 4.0.

En gros je dirais que si on change les règles du jeu du point de vue de l'extérieur (surface d'exposition web), alors c'est une majeure, si on ne fait que changer la tuyauterie interne (quand bien même ça implique de gros refactos pour les projets clients), c'est une mineure.

On peut commencer par créer "release/3.0" comme tu avais fait pour la 2.x

[rducom]

Les règles du SemVer sont les règles du semver...
Je vous propose de faire la montée de version sur le wsftp vers la dernière build de master, et si je trouve rien de bloquant, je créé la release 3.0

[nfaugout-lucca]

Les règles du SemVer sont les règles du semver...

Ouais je sais mais je trouve ça pourri, car tes numéros de majeure ne veulent plus rien dire. Par ex si un BUG FIX te contraint à faire un breaking change, alors tu dois monter le numéro de majeure ?! Autant que si tu fais un refacto complet de ton projet, je trouve ça bizarre.

Ce que je veux dire c'est que la "distance" entre 2 versions majeure n'est plus palpable comme elle pourrait l'être si on disait plutôt :

MAJOR = breaking changes structurant, changement de paradigme
MINOR = nouvelles features, breaking changes léger
PATCH = refacto sans breaking changes, FIX sans breaking changes

C'est juste sur MINOR finalement que j'ai du mal..

D'ailleurs si on suit SemVer, on devrait alors référencer les packages avec 2 étoiles : v2.. ou v2.*

Bref, on peut adopter SemVer à partir de la 3.0 (d'ailleurs on ne devrait pas dire 3.0 mais 3 vu que .0 n'a plus aucun "poids" vu que .1 ce sera sans breaking changes)

[rducom]

https://semver.org/

Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

=> On parle de l'api c# exposés aux devs, pas de l'api au sens json du terme. Introduire les retours typés sur les controllers rentre dans cette catégorie, de même pour la suppression de la sérialisation custom

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

Minor = on est rétrocompatible, et on ajoute de la feature.

"Breaking change léger" ça n'existe pas ;)

[nfaugout-lucca]

=> On parle de l'api c# exposés aux devs, pas de l'api au sens json du terme. Introduire les retours typés sur les controllers rentre dans cette catégorie, de même pour la suppression de la sérialisation custom

Oui merci j'avais compris ;)

"Breaking change léger" ça n'existe pas ;)

Voilà c'est ça mon point, de ne pas faire la différence entre les types de breaking changes. Y'a le petit breaking change, qui va te prendre 2mn à ajuster dans ton projet (changer le nom d'une méthode, ajouter/retirer un paramètre, changer un type), et le gros breaking change, que je qualifierait de structurel et pour lequel tu vas devoir revoir la structure même de ton appli.

Par ex c'est ce qui s'est passé entre AngularJS et Angular, ils ont carrément changé de repo. Nous dans Rdd, je me voit mal changer de nom à chaque gros changements, et j'aurais donc aimé que ça puisse se traduire en SemVer, mais ce n'est pas grave, je vais m'y faire ;)

[GMouron]

Il y a des choses qu'on croit être des petits breaking change et qui en fait en sont des gros. Exemple :
EnumConstraint dans NExtends.
L'idée de semver, c'est de se dire que tu peux bumper sur ton projet une mineur sans aucun soucis. Dès que tu as un breaking change, tu as un souci.

[nfaugout-lucca]

Il y a des choses qu'on croit être des petits breaking change et qui en fait en sont des gros. Exemple :
EnumConstraint dans NExtends.

M'en parle pas je suis dessus :D

L'idée de semver, c'est de se dire que tu peux bumper sur ton projet une mineur sans aucun soucis. Dès que tu as un breaking change, tu as un souci.

Oui j'ai bien compris, mais j'aurais trouvé plus adapté pour nous que le bump automatique soit uniquement sur les PATCH, et que les MINEURE puissent avoir des breaking changes, mais c'est pas très grave.

Par contre adopter SemVer, ça sous entend le fonctionnement suivant :

• on imagine une v3 en prod
• on veut faire des FIX dont certains qui comportent des breaking changes
  -- il faut alors faire des FIX sans breaking change (donc adapter les FIX) pour sortir une mineure 3.1
  -- et prévoir pour la v4 la "bonne" version des FIX avec breaking change

Car on ne va pas s'amuser à faire une v4 juste pour 1 FIX qui a un breaking change.

Ca sous entend donc une plus grande rigueur dans les releases ET parfois faire 2 fois le boulot (une fois pour sortir une MINEUR rapidos, une 2ème fois pour la prochaine MAJEUR

On est d'accord là-dessus ?

[rducom]

Tout à fait, d'où l'idée de bien réfléchir à ce qu'on met ou pas dans une next MAJOR, et de ne pas se hâter à sortir une release juste pour sortir une release. Il faut profiter des major pour avancer le plus possible vers une surface d'API suffisamment découplé de façon à ce qu'elle bouge le minimum à l'avenir.
Lorsque la surface externe est stable, on fait que des MINORS sans pb.

D'où mon envie de profiter de la future 3.0 pour faire les modifs de types de retours et de serialisation, qui sont des vrais beakings changes, MAIS qui une fois passés n'auront plus à passer (et j'ai pas d'autre gros breaking change à faire passer à part ceux là)

[nfaugout-lucca]

La question c'est à quelle fréquence on pense sortir des MAJOR, si c'est une fois par an alors en effet on peut attendre tes 3 PR, mais si on part sur 3 ou 4 fois par an, alors dans ce cas on peut sortir une 3 et une 4 à la fin de l'année avec tes 3 PR.