Autofixture: Diskussion: Das Namespace-Präfix 'Ploeh'

Meines Wissens hat die überwiegende Mehrheit der OSS-Projekte den Root-Namespace identisch mit dem Namen, daher sehe ich hier keine Probleme. Da dies eine bahnbrechende Änderung wäre, müssen Sie nur die Hauptversion inkrementieren.

👍 um den Root-Namespace in einer Breaking-Version in AutoFixture zu ändern.

Es macht mir nichts aus, den Ploeh-Namespace zu behalten. Das Eigentum bezieht sich nicht und
Namensraumänderungen für Dinge, die perfekt funktionieren, warum...?

Am Sonntag, 2. April 2017 um 14:04 Uhr schrieb Adam Ralph [email protected] :

👍 um den Root-Namespace in einer Breaking-Version in AutoFixture zu ändern.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

Ich stimme der Gesamtanalyse (die oben genannten Vor- und Nachteile) zu.

Wie bereits von mehreren hier angemerkt, wäre die Änderung des Namensraums eine bahnbrechende Änderung. OTOH scheint die Änderung des Namensraums zwischen Version 3 und Version 4 aufgrund der geänderten Governance zumindest vertretbar zu sein. Es wäre viel schwieriger, das Entfernen von 'Ploeh' zwischen Version 4 und Version 5 zu verteidigen.

Wenn Sie 'Ploeh' aus dem Namespace entfernen möchten, ist jetzt der richtige Zeitpunkt dafür.

@ploeh Danke für die Antwort. Noch eine Frage an Sie – welche Option bevorzugen Sie persönlich? :) Ich weiß, dass dies eine etwas knifflige Frage ist, aber ich glaube, dass ich nicht der einzige bin, für den es wichtig ist, da Sie ein Gründer sind (oder Mitgründer, ich bin mir nicht sicher :flush :)).

Ich bevorzuge es, dass Sie die Entscheidung treffen, die Ihrer Meinung nach die beste für das weitere Projekt ist 😉

Aus externer Sicht kann ich sagen, dass der Namespace Ploeh.Autofixture meine ersten Verwendungen der Bibliothek etwas schwieriger machte, da der Namespace weder mit dem Paketnamen noch mit dem Projekt hier auf GitHub zusammenhängt.

Es ist eine Überraschung, using Auto... einzugeben und eine leere Liste von Intellisense zu erhalten.

Ich stimme @Kralizek zu.
Aber das Problem mit der Umbenennung des Projekts in Fixture.Net (obwohl ich diesen Schritt persönlich unterstützen würde) würde bedeuten, mit dem ziemlich breiten und bekannten Namen der .NET-Community zu brechen.

Stimmt mit dem @ploeh geschrieben hat

Wenn Sie 'Ploeh' aus dem Namespace entfernen möchten, ist jetzt der richtige Zeitpunkt dafür.

Dies kann natürlich nur im v4 Zweig passieren.

Eine Namespace-Änderung ist eher einfach, Suchen & Ersetzen und Ihr erfolgt in Ihrem eigenen Quellcode.

Das Problem liegt bei nuget, wenn andere Pakete AutoFixture verwenden und nicht das richtige Versionstrennzeichen in der nuspec haben, dann wird dies auch kaputt gehen. Aber vorerst kann der Benutzer problemlos zu AutoFixture 3.x zurückkehren. Dies kann in der Dokumentation, dem Release Blog-Beitrag oder was auch immer angesprochen werden.

Ich bin dafür, Ploeh aus dem Namespace zu entfernen, ich würde nie persönliche Namen im Namespace mögen, habe das früh in meinen Projekten gemacht, hasste mich dafür ;)

Wenn andere Pakete AutoFixture verwenden und nicht das richtige Versionstrennzeichen in der Nuspec haben, wird dies auch kaputt gehen

Ich würde mir keine Sorgen machen. Das gleiche Problem besteht für jede brechende Version. Wenn Downstream-Pakete sich entschieden haben, keine exklusive Obergrenze für die nächste Hauptversion festzulegen, zB <dependency id="AutoFixture" version="[3.0,4.0)" /> , dann fordern sie dieses Problem jedes Mal auf, wenn eine Hauptversion von AutoFixture veröffentlicht wird.

@abatishchev Kommt Fixture.Net aus einer anderen Diskussion? Ich wäre ziemlich glücklich, wenn ich einfach den Namespace in AutoFixture

@moodmosaic Könnten Sie dazu auch Ihre Position hinzufügen? Ich glaube, dass wir die Meinungen aller Core-Maintainer haben müssen, um die endgültige Entscheidung zu treffen.

Ι tat bereits.

@moodmosaic Ich habe diese Antwort gesehen, bin mir aber nicht sicher, ob ich deine Position habe. Stimmen Sie dafür, den Namensraum beizubehalten oder zu entfernen? :)

Ich stimme dafür, es zu behalten. Weniger störend.

Warum stört es Sie, störende Dinge zu tun? Viele Leute fordern diese Änderung.
Noch weniger störend wäre, das Projekt unverändert zu belassen und keinerlei Änderungen vorzunehmen. Aber darum geht es bei diesem ganzen Prozess nicht, oder?
Ich persönlich würde mich freuen, wenn Sie diese Veränderung vorantreiben.

@moodmosaic Ich habe diese Antwort gesehen, bin mir aber nicht sicher, ob ich deine Position habe.

Ich wäre in Ordnung, wenn der Root-Namespace in v4 in nur AutoFixture umbenannt

Während ich zu meiner vorherigen Stimme für die Beibehaltung des Namensraums Ploeh stehe, bin ich damit einverstanden, dass er entfernt wird, wenn dies das ist, was die meisten Leute wollen.

Angesichts des Eigentümerwechsels sehe ich, wie es für das weitere Projekt sinnvoll wäre und der Zeitpunkt ist reif. Die einzigen Gegenargumente, die mir einfallen, basieren derzeit ausschließlich auf Emotionen.

@ecampidoglio , ich hatte auch Emotionen, aber ich denke, es ist "richtiger" mit nur _AutoFixture_ in v4 ...

@moodmosaic Danke für die Antwort, das gleiche passiert mir tatsächlich. Je mehr ich dieses Projekt lerne, desto mehr sehe und realisiere ich die Menge an Arbeit, die Mark hier geleistet hat - eine große Anzahl verschiedener Diskussionen, kleinere Optimierungen, Antworten auf SO usw. Es wird immer schwieriger, die Entscheidung zu treffen, das Präfix zu trimmen - it sieht in Bezug auf Mark undankbar aus.

Von der anderen Seite verstehe ich, dass das einfache Präfix AutoFixture viel besser und konsistenter aussehen wird. In der Tat, es gibt nichts hier schrecklich, als Mark Name noch vorhanden sein wird , in der Liste der Paketautoren, dem Wiki, Fragen .. Mit @adamchester und @ecampidoglio Stimmen das Präfix zu halten es schwieriger wird auch die Entscheidung zu treffen - viele emotionales Zeug ist hier vorhanden. Wahrscheinlich sollten wir den emotionalen Aspekt trennen und die Dinge nicht durcheinander bringen. Ich persönlich betrachte das Trimmen von Namensräumen nicht als Akt der Abwertung von Marks Arbeit - für mich ist der Grund eine reine Haushaltsführung. Ich werde ihm immer noch sehr dankbar sein, auch wenn das Präfix fehlt.

Da ich jedoch zu spät mit der Arbeit an einem Projekt begonnen habe (und mich niemand kennt), habe ich das Gefühl, dass ich den Beitrag von Mark nicht vollständig verstehen kann und daher sollte das letzte Wort definitiv bei den Hauptmitwirkenden liegen.

@zvirja Ich glaube, du hast meinen vorherigen Kommentar falsch verstanden:

Ich bin damit einverstanden, dass es entfernt wird, wenn es das ist, was die meisten Leute wollen.

Also, ja, ich würde es lieber behalten, aber ich bin mit dem AutoFixture Namespace in v4 einverstanden. 😉

Meine Meinung ist grundsätzlich die gleiche wie @ecampidoglio - Ich würde eher den Namensraum halten , wie sie ist nur unnötige Unterbrechungen der Benutzer zu vermeiden, aber ich bin OK mit ihm nur der Änderung AutoFixture in v4.

es sieht undankbar in Bezug auf Mark aus.

Mach dir darüber keine Sorgen. Der beste Dank, den Sie mir jemals geben können, ist, AutoFixture am Leben zu erhalten. Wenn Sie das können, ist es mir gelungen, etwas zu schaffen, das für sich allein tragfähig ist. Wenige Dinge könnten zufriedenstellender sein.

Danke für die Antwort, Markus!

Angesichts all der obigen Antworten und der Tatsache, dass das Kernteam nichts dagegen hat, den Namespace zu ändern, füge ich dies dem v4-Bereich hinzu.

Das ist eine weitere Sache, die ich übersehen habe, um zu fragen - Assembly-Namen. Es scheint, dass derzeit auch Assemblynamen mit dem Ploeh beginnen. Wenn wir das Namespace-Präfix entfernen, ist es sinnvoll, auch Assemblys umzubenennen (zB von Phoeh.AutoFixture.dll in AutoFixture.dll ). Ich glaube, dass NuGet diese Änderung elegant handhaben wird. Das einzige, worüber wir uns Sorgen machen könnten, ist, dass dies eine neue Assemblyidentität ist und es unmöglich sein wird, eine Assemblyumleitung von v3 auf v4 durchzuführen.

Was halten Sie von diesem @moodmosaic , @adamchester und @ecampidoglio - haben Sie Einwände gegen die Umbenennung der Assembly? Es sieht nach einer wichtigen Änderung aus, ist aber noch nicht bereit zu bewerten, wie viel.

Sobald die Namespaces in v4 umbenannt wurden, ist die Umleitung der Assemblybindung auf v4 bedeutungslos. Aus diesem Grund und aus Gründen der Konsistenz ist es meiner Meinung nach sinnvoll, die Assemblys in AutoFixture(.*) umzubenennen.

Guter Punkt, das habe ich übersehen. Tatsächlich sind alle vollständigen Namen des Typs unterschiedlich, sodass eine Umleitung keinen Sinn macht. Sofern @adamchester und @ecampidoglio keine anderen Bedenken haben - ändern wir auch die Namen.

Fertig! Der Namespace "Ploeh" und das Namenspräfix der Assembly werden aus v4 entfernt, sodass es stattdessen mit "AutoFixture" beginnt. Diese Änderung ermöglicht es, das aktualisierte Eigentum widerzuspiegeln, da das Produkt jetzt nur vom AutoFixture-Team entwickelt wird.

Bedenken Sie, dass dies die Kontinuitätslinie für die Versammlung bricht. Dh, das neue Paket enthält keine neue Version der Assembly. Stattdessen wird die vorherige Baugruppe entfernt und durch eine völlig neue Baugruppe mit einer neuen Identität ersetzt. Das bedeutet, dass Dinge wie Binding Redirects zwischen der in Paket 3.x enthaltenen Assembly und der in 4.x enthaltenen Assembly nicht funktionieren können.

Vielleicht ist das kein Problem, aber ich dachte, es lohnt sich, darauf hinzuweisen.

Übrigens – haben Sie das Verhalten von NuGet beim Upgrade des Pakets überprüft? Für Projekte im SDK-Stil wird alles gut funktionieren, da das Projekt nur ein <PackageReference> Element enthält, das auf das Paket und nicht auf Assemblys verweist. Bei csproj im alten Stil kann es sich jedoch lohnen, zu überprüfen, ob NuGet die gewünschte Änderung an der Assemblyreferenz von einer Assembly zur anderen vornimmt.

@adamralph Danke für deine Bedenken!

Das bedeutet, dass Dinge wie Binding Redirects zwischen der in Paket 3.x enthaltenen Assembly und der in 4.x enthaltenen Assembly nicht funktionieren können.

Ja, das kenne ich. Wir haben jedoch bereits den Standard-Namespace geändert, dh wir haben die Identität für alle Typen innerhalb der Assemblys geändert. In dieser leichten Assembly macht die Bindungsumleitung keinen Sinn, da Code ohne Neukompilierung und Importkorrektur auf keinen Fall funktioniert. Daher glaube ich, dass wir damit völlig in Ordnung sind. Es ist eine große Veränderung, aber es wird nur einmal passieren.

Übrigens – haben Sie das Verhalten von NuGet beim Upgrade des Pakets überprüft?

Ja, das habe ich schon getestet und es funktioniert einwandfrei. Das einzige, was Sie tun müssen, ist die Textersetzung auszuführen, um using Ploeh.AutoFixture in using AutoFixture . Danach wird das Projekt erfolgreich kompiliert und die Tests werden erfolgreich ausgeführt.

Das einzige, was Sie tun müssen, ist die Textersetzung auszuführen, um die Verwendung von Ploeh.AutoFixture auf die Verwendung von AutoFixture zu korrigieren. Danach wurde das Projekt erfolgreich kompiliert und erfolgreich getestet.

Ja genau.