Autofixture: Discussion : Le préfixe d'espace de noms 'Ploeh'

À ma connaissance, la grande majorité des projets OSS ont l'espace de noms racine identique au nom, donc je ne vois aucun problème ici. Comme il s'agirait d'un changement décisif, il vous suffit d'incrémenter la version majeure.

👍 pour changer l'espace de noms racine en AutoFixture dans une version de rupture.

Cela ne me dérange pas de garder l'espace de noms Ploeh. La propriété n'est pas liée et
l'espace de noms change sur des choses qui fonctionnent parfaitement, pourquoi..?

Le dimanche 2 avril 2017 à 14h04, Adam Ralph [email protected] a écrit :

👍 pour changer l'espace de noms racine en AutoFixture dans une version de rupture.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

Je suis d'accord avec l'analyse globale (les avantages et les inconvénients décrits ci-dessus).

Comme déjà noté par plusieurs personnes ici, changer l'espace de noms serait un changement décisif. OTOH, changer l'espace de noms entre la version 3 et la version 4 semble pour le moins défendable, du fait du changement de gouvernance. Il serait beaucoup plus difficile de défendre la suppression de « Ploeh » entre la version 4 et la version 5.

Si vous souhaitez supprimer 'Ploeh' de l'espace de noms, c'est le moment de le faire.

@ploeh Merci pour la réponse. Une dernière question pour vous - quelle option préférez-vous personnellement ? :) Je sais que c'est une question un peu délicate, mais je crois que je ne suis pas le seul pour qui cela compte, car vous êtes fondateur (ou co-fondateur, je ne suis pas sûr :flushed:).

Je préfère que vous preniez la décision que vous jugez la meilleure pour l'avancement du projet 😉

D'un point de vue externe, je peux dire que le fait d'avoir l'espace Ploeh.Autofixture noms

C'est une sorte de surprise de taper using Auto... et de recevoir une liste vide d'Intellisense.

Je suis d'accord avec @Kralizek.
Mais le problème de renommer le projet en Fixture.Net (malgré personnellement je soutiendrais cette étape) signifierait rompre avec le nom de la communauté .NET assez large et bien connu.

D'accord avec ce que @ploeh a écrit

Si vous souhaitez supprimer 'Ploeh' de l'espace de noms, c'est le moment de le faire.

Bien sûr, cela ne peut se produire que dans la branche v4 .

Un changement d'espace de noms est plutôt facile, recherchez et remplacez et vous le faites dans votre propre code source.

Le problème est avec nuget si d'autres packages utilisent AutoFixture et n'ont pas le bon délimiteur de version dans le nuspec, cela se brisera également. Mais pour le moment, l'utilisateur peut facilement revenir à AutoFixture 3.x. Cela peut être abordé dans la documentation, le blog de publication ou autre.

Je suis pour la suppression de Ploeh de l'espace de noms, je n'aimerais jamais de noms personnels dans l'espace de noms, je l'ai fait au début de mes projets, je me détestais de faire ça ;)

si d'autres packages utilisent AutoFixture et n'ont pas le bon délimiteur de version dans le nuspec, cela se brisera également

Je ne m'en inquiéterais pas. Le même problème existe pour chaque version de rupture. Si les packages en aval ont choisi de ne pas mettre de limite supérieure exclusive sur la prochaine version majeure, par exemple <dependency id="AutoFixture" version="[3.0,4.0)" /> , alors ils invitent ce problème à chaque fois qu'une version majeure d'AutoFixture est publiée.

@abatishchev Est-ce que Fixture.Net vient d'une autre discussion ? Je serais assez heureux en changeant simplement l'espace de noms en AutoFixture

@moodmosaic Pourriez-vous également ajouter votre position à ce sujet ? Je crois que nous avons besoin d'avoir tous les avis des principaux responsables pour prendre la décision finale.

Je l' ai déjà fait.

@moodmosaic J'ai vu cette réponse, mais je ne suis pas sûr d'avoir compris votre position. Votez-vous pour conserver l'espace de noms ou pour le supprimer ? :)

Je vote pour le garder. Moins perturbateur.

Pourquoi faire des choses perturbatrices vous préoccupe ? Beaucoup de gens demandent ce changement.
Encore moins perturbateur serait de laisser le projet tel quel, sans aucun changement. Mais ce n'est pas le but de tout ce processus, n'est-ce pas ?
Personnellement, j'aimerais que vous alliez de l'avant avec ce changement.

@moodmosaic J'ai vu cette réponse, mais je ne suis pas sûr d'avoir compris votre position.

Je serais d' accord si l'espace de noms racine était renommé en v4 .

Bien que je maintiens mon vote précédent pour le maintien de l'espace Ploeh noms

Compte tenu du changement de propriétaire, je vois en quoi cela aurait du sens pour le projet à l'avenir et le moment est venu. À ce stade, les seuls contre-arguments que je peux proposer sont uniquement basés sur les émotions.

@ecampidoglio , j'avais aussi des émotions, mais je pense que c'est plus "correct" avec juste _AutoFixture_ en v4...

@moodmosaic Merci pour la réponse, la même chose m'arrive en fait. Plus j'apprends ce projet, plus je vois et réalise la quantité de travail que Mark a fait ici - un grand nombre de discussions différentes, des ajustements mineurs, des réponses sur SO, etc. Il devient de plus en plus difficile de prendre la décision de couper le préfixe - il semble ingrat vis-à-vis de Mark.

De l'autre côté, je comprends que le simple préfixe AutoFixture sera bien meilleur et cohérent. En fait, il n'y a rien d'horrible ici, car le nom de Mark sera toujours présent dans la liste des auteurs du paquet, du wiki, des problèmes. Avec @adamchester et @ecampidoglio votent pour garder le préfixe, il devient encore plus difficile de prendre la décision - beaucoup de des trucs émotionnels sont présents ici. Probablement, nous devrions séparer l'aspect émotionnel et ne pas mélanger les choses. Personnellement, je ne considère pas le découpage des espaces de noms comme un acte de dépréciation du travail de Mark - pour moi, la raison en est un pur ménage. Je lui serai toujours très reconnaissant même si le préfixe est absent.

Cependant, étant donné que j'ai commencé à travailler sur le projet trop tard (et personne ne me connaît), je pense que je ne peux pas comprendre pleinement la contribution de Mark et, par conséquent, le dernier mot devrait appartenir aux principaux contributeurs.

@zvirja je pense que tu as mal compris mon commentaire précédent :

Je suis d'accord pour qu'il soit supprimé si c'est ce que la plupart des gens veulent.

Donc, oui, je préfère le garder mais je suis d'accord avec l'espace AutoFixture noms

Mon opinion est fondamentalement la même que @ecampidoglio - je préfère garder l'espace de noms tel AutoFixture dans la v4.

il semble ingrat vis-à-vis de Mark.

Ne t'inquiète pas pour ça. Le meilleur merci que vous puissiez me donner est de garder AutoFixture en vie. Si vous pouvez le faire, j'ai réussi à créer quelque chose de viable en soi. Peu de choses pourraient être plus satisfaisantes que cela.

Merci pour la réponse, Marc !

Compte tenu de toutes les réponses ci-dessus et étant donné que l'équipe principale ne craint pas de changer l'espace de noms, je vais l'ajouter à la portée v4.

C'est une autre chose que j'ai oublié de demander - les noms d'assembly. Il semble qu'actuellement, les noms d'assembly commencent également par le Ploeh. Si nous supprimons le préfixe d'espace de noms, il est logique de renommer également les assemblys (par exemple de Phoeh.AutoFixture.dll à AutoFixture.dll ). Je pense que NuGet gérera ce changement avec élégance. La seule chose dont nous pourrions nous inquiéter est qu'il s'agira d'une nouvelle identité d'assembly et qu'il sera impossible d'effectuer une redirection d'assembly de v3 vers v4.

Que pensez-vous de ce @moodmosaic , @adamchester et @ecampidoglio - avez-vous des objections concernant le changement de nom de l'assembly ? Cela ressemble à un changement important, mais pas prêt à évaluer à quel point.

Une fois les espaces de noms renommés en v4, la redirection de liaison d'assembly vers v4 n'aura plus de sens. Pour cette raison, et pour être cohérent, je pense qu'il est logique de renommer les assemblys en AutoFixture(.*).

Bon point, j'ai raté ça. En effet, tous les noms complets de type seront différents, donc la redirection n'a pas de sens. À moins que @adamchester et @ecampidoglio aient d'autres préoccupations, changeons également les noms.

Terminé! L'espace de noms "Ploeh" et le préfixe du nom de l'assembly seront supprimés de la v4, de sorte qu'il commencera par "AutoFixture" à la place. Ce changement permet de refléter la propriété mise à jour car le produit est désormais développé par l'équipe AutoFixture uniquement.

Gardez à l'esprit que cela rompt la ligne de continuité en ce qui concerne l'assemblage. C'est-à-dire que le nouveau package ne contiendra pas une nouvelle version de l'assembly. Au lieu de cela, l'assemblage précédent sera supprimé et remplacé par un assemblage complètement nouveau, avec une nouvelle identité. Cela signifie que des choses comme les redirections de liaison ne peuvent pas fonctionner entre l'assembly contenu dans le package 3.x et l'assembly contenu dans 4.x.

Ce n'est peut-être pas un problème, mais j'ai pensé que cela valait la peine de le souligner.

BTW - avez-vous vérifié le comportement de NuGet lorsque le package est mis à niveau ? Pour les projets de style SDK, je suppose que tout fonctionnera très bien, car le projet ne contient qu'un élément <PackageReference> pointant vers le package plutôt que des assemblys. Mais avec l'ancien style csproj, il peut être utile de vérifier que NuGet apporte la modification souhaitée à la référence d'assembly, d'un assembly à l'autre.

@adamralph Merci pour vos inquiétudes !

Cela signifie que des choses comme les redirections de liaison ne peuvent pas fonctionner entre l'assembly contenu dans le package 3.x et l'assembly contenu dans 4.x.

Ouais, je le sais. Cependant, nous avons déjà modifié l'espace de noms par défaut, ce qui signifie que nous avons modifié l'identité de tous les types au sein des assemblys. Dans cette lumière, la redirection de liaison d'assembly n'aura aucun sens car le code ne fonctionnera en aucun cas sans une recompilation et un correctif d'importation. Par conséquent, je pense que nous sommes tout à fait d'accord avec cela. C'est un énorme changement, mais cela ne se produira qu'une seule fois.

BTW - avez-vous vérifié le comportement de NuGet lorsque le package est mis à niveau ?

Oui, j'ai déjà testé ça et ça marche très bien. La seule chose que vous devez faire est d'exécuter le remplacement de texte pour corriger le using Ploeh.AutoFixture à using AutoFixture . Une fois ce projet compilé et les tests exécutés avec succès.

La seule chose que vous devez faire est d'exécuter le remplacement de texte pour corriger l'utilisation de Ploeh.AutoFixture à l'utilisation d'AutoFixture. Après ce projet compilé et testé avec succès.

Oui, exactement.