New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: The 'Ploeh' namespace prefix #745
Comments
To my knowledge the vast majority of OSS projects have the root namespace identical to the name so I don't see any issues here. Since this would be a breaking change you just need to increment major version. |
👍 to change the root namespace to |
I dont mind keeping Ploeh namespace. The ownership doesnt relate and
namespace changes on things that are working perfectly, why..?
…On Sun, 2 Apr 2017 at 14:04 Adam Ralph ***@***.***> wrote:
👍 to change the root namespace to AutoFixture in a breaking version.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#745 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd>
.
|
I agree with the overall analysis (the pros and cons outlined above). As already noted by several people here, changing the namespace would be a breaking change. OTOH, changing the namespace between version 3 and version 4 seems at least defendable, due to the change in governance. It'd be much harder to defend removing 'Ploeh' between version 4 and version 5. If you want to remove 'Ploeh' from the namespace, now is the time to do it. |
@ploeh Thanks for the reply. One more question to you - which option do you personally prefer? :) I know that this a bit tricky question, but I believe that I'm not the only one for whom it does matter, as you are a founder (or co-founder, I'm not sure 😳). |
I prefer that you reach the decision that you believe is the best for the project moving forward 😉 |
From an external perspective, I can tell that having the namespace It's kind of a surprise to type |
I agree with @Kralizek. |
A Namespace change is rather Easy, Search & Replace and your done in your own source code. The Problem is with nuget if other packages are using AutoFixture and don't have the right Version delimiter in the nuspec then this will also break. But for the time beeing the user can easy go back to AutoFixture 3.x. This can be adressed in the Documentation, Release Blog post or whatever. I'm for removing Ploeh from the Namespace, I'd never like Personal Namees in the Namespace, did this early in my projects, hated me for doing that ;) |
I wouldn't worry about it. The same problem exists for every breaking version. If downstream packages have chosen not to put an exclusive upper bound on the next major version e.g. |
@abatishchev Is |
@moodmosaic Could you also add your position about this? I believe that we need to have all core maintainers opinions to make the final decision. |
Ι did already. |
@moodmosaic I saw that answer, but I am not sure I got your position. Do you vote to keep the namespace or to remove it? :) |
I vote for keeping it. Less disruptive. |
Why doing disruptive things concerns you? A lot of people ask for this change. |
I'd be fine by me, if the root namespace gets renamed to just AutoFixture in |
While I stand by my previous vote for keeping the Given the change in ownership, I see how it would make sense for the project going forward and the time is right. At this point, the only counterarguments I can come up with are solely based on emotions. |
@ecampidoglio, I was having emotions as well, but I think it's more 'correct' with just AutoFixture in v4... |
@moodmosaic Thanks for the reply, the same thing actually happens to me. The more I learn this project, the more I see and realize amount of work Mark did here - huge number of different discussions, minor tweaks, replies on SO, etc. It becomes harder and harder to make the decision to trim the prefix - it looks unthankful with respect to Mark. From other side, I do understand that simple However given that I started to work on project too late (and nobody knows me), I feel that I cannot fully understand the Mark's contribution and, therefore, the final word should be definitely up to the core contributors. |
@zvirja I think you misunderstood my previous comment:
So, yes, I'd rather keep it but I'm OK with the |
My opinion is basically the same as @ecampidoglio - I'd rather keep the namespace as-is only to avoid needless disruptions to users, but I'm OK with changing it to just |
Don't worry about that. The best thanks you can ever give me is to keep AutoFixture alive. If you can do that, I've succeeded in creating something that's viable in its own right. Few things could be more satisfactory than that. |
Thank you for the reply, Mark! Given all the replies above and given that the core team doesn't mind to change the namespace, I'll add this to the v4 scope. The is one more thing which I overlooked to ask about - assembly names. It appears that currently assembly names start with the Ploeh as well. If we remove the namespace prefix, it makes sense to rename assemblies as well (e.g. from What do you think about this @moodmosaic, @adamchester and @ecampidoglio - do you have objections regarding the assembly rename? It looks like an important change, but not ready to evaluate how much. |
Once the namespaces get renamed in v4, assembly binding redirection to v4 will be meaningless. For this reason, and to be consistent, I think it makes sense to rename the assemblies to AutoFixture(.*). |
Good point, I missed that. Indeed, all the type full names will be different, so redirection doesn't make sense. Unless @adamchester and @ecampidoglio have other concerns - let's change the names as well. |
Done! The "Ploeh" namespace and assembly name prefix will be removed from v4, so that it will start with "AutoFixture" instead. This change allows to reflect the updated ownership as now product is being developed by the AutoFixture team only. |
Bear in mind that this breaks the line of continuity as far as the assembly is concerned. I.e., the new package will not contain a new version of the assembly. Rather, the previous assembly will be removed, and replaced by a completely new assembly, with a new identity. This means that things like binding redirects cannot be made to work between the assembly contained in package 3.x and the assembly contained in 4.x. Perhaps this isn't a problem, but I thought it's worth pointing out. |
BTW - have you checked the behaviour of NuGet when the package is upgraded? For SDK style projects, I guess everything will work just fine, since the project only contains a |
@adamralph Thanks for your concerns!
Yep, I know that. However, we have already changed the default namespace, meaning we changed identity for all the types within the assemblies. In this light assembly binding redirection will make no sense as code will not work in any case without re-compilation and imports fix. Therefore, I believe we are totally fine with that. It's a huge change, but it will happen for one time only.
Yep, I've already tested that and it works fine. The only thing you need to do is to run the text replace to fix the |
Yes, exactly. |
By opening this ticket I want to understand our position regarding the 'Ploeh.AutoFixture' namespace we currently have in AutoFixture and what is our vision regarding it in future. This question already arose and we will definitely meet it in future again :)
There are 2 ways how we could behave - keep it as is or remove the
Ploeh
prefix. Each option has this pros and cons.Keep as is
The idea is to keep the
Ploeh
prefix in all the namespaces for now, despite the fact that Mark isn't the owner of the repo more.Pros:
v4
.Cons:
Very unclear ownership. As Mark stated here, a lot of people still think that he is the owner of the repository. If we keep the namespace prefix, this confusion will be still present.
On other side, if we remove it - his name will not be present in all the imported namespaces more, so after some time confusion will disappear.
Confusion from consumers. It looks similar to the point 1, but the difference is that not everybody knows who is the
Ploeh
. It might be unclear to the new (and existing) consumers why do we have this unusual prefix :)Change the prefix
The option is to alter all the files in all the projects and remove the
Ploeh
prefix. Technically it's easy to do, so question is only about our decision.The pros and cons are the same as for the Keep as is option:
Pros:
Ownership. It will be clear that AutoFixture is a standalone organization that manages the project by itself. The Mark (Ploeh) doesn't lead the project more. Also less people will think that this project belongs to Mark.
Simplified namespace. That will remove unnecessary word from the namespace, so will make namespace imports less verbose.
Cons:
v4
will be forced to change namespace imports. Also, it could happen that full type names are hardcoded somewhere as strings. Of course, it will be done only once and it's easy to do, but there are people who don't track all this ownership stuff and just use the AF - it will pretty boring for them.First of all I'd like to hear the @ploeh opinion about this change and which way he personally prefers. You, Mark, invested a lot here so your vision does matter.
Also I'd like to involve guys from the core team: @ecampidoglio, @moodmosaic and @adamchester.
After we decide, we'll have an issue with our decision, so later we could forward anybody who asks/disagrees here :)
The text was updated successfully, but these errors were encountered: