Autofixture: Discussion: The 'Ploeh' namespace prefix

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 AutoFixture in a breaking version.

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 notifications@github.com 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
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395,
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 :flushed:).

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 Ploeh.Autofixture made my first usages of the library slightly harder because the namespace is not related to either the package name or the project here on GitHub.

It's kind of a surprise to type using Auto... and receiving an empty list from Intellisense.

I agree with @Kralizek.
But the problem with renaming project to Fixture.Net (spite personally I'd support this step) would mean breaking with pretty wide and well known in the .NET community name.

Agreed with what @ploeh wrote

If you want to remove 'Ploeh' from the namespace, now is the time to do it.

Of course, this may only happen in the v4 branch.

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 ;)

if other packages are using AutoFixture and don't have the right Version delimiter in the nuspec then this will also break

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. <dependency id="AutoFixture" version="[3.0,4.0)" />, then they are inviting this problem every time a major version of AutoFixture is released.

@abatishchev Is Fixture.Net coming from another discussion? I'd be pretty happy by simply changing the namespace to AutoFixture

@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.
Even less disruptive would be leaving the project as-is, making no changes at all. But that's not what all this process is about, isn't it?
I personally would like to see you going ahead with this change.

@moodmosaic I saw that answer, but I am not sure I got your position.

I'd be fine by me, if the root namespace gets renamed to just AutoFixture in v4.

While I stand by my previous vote for keeping the Ploeh namespace, I'm fine with it being removed if that's what most people wants.

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 AutoFixture prefix will look much better and consistent. In fact, there nothing horrible here, as Mark's name will still be present in list of the package authors, wiki, issues.. With @adamchester and @ecampidoglio votes to keep the prefix it becomes even harder to make the decision - a lot of emotional stuff is present here. Likely, we should separate the emotional aspect and to not mix the things up. Personally, I don't treat namespace trimming as act of depreciation Mark's work - for me the reason is a pure homekeeping. I will still be very thankful to him even if the prefix is absent.

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:

I'm fine with it being removed if that's what most people wants.

So, yes, I'd rather keep it but I'm OK with the AutoFixture namespace in v4. 😉

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 AutoFixture in v4.

it looks unthankful with respect to Mark.

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 Phoeh.AutoFixture.dll to AutoFixture.dll). I believe that NuGet will handle this change gracefully. The only thing we could worry about is that this will be a new assembly identity and it will be impossible to perform assembly redirect from v3 to v4.

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 <PackageReference> element pointing to the package rather than assemblies. But with old style csproj, it may be worth verifying that NuGet makes the desired change to the assembly reference, from the one assembly to another.

@adamralph Thanks for your concerns!

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.

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.

BTW - have you checked the behaviour of NuGet when the package is upgraded?

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 using Ploeh.AutoFixture to using AutoFixture. After that project successfully compiles and tests run successfully.

The only thing you need to do is to run the text replace to fix the using Ploeh.AutoFixture to using AutoFixture. After that project successfully compiled and test run successfully.

Yes, exactly.