Autofixture: Discussão: O prefixo de namespace 'Ploeh'

Pelo que sei, a grande maioria dos projetos de software de fonte aberta tem o namespace raiz idêntico ao nome, então não vejo nenhum problema aqui. Uma vez que esta seria uma alteração significativa, você só precisa incrementar a versão principal.

👍 para alterar o namespace raiz para AutoFixture em uma versão de última hora.

Não me importo em manter o namespace Ploeh. A propriedade não se relaciona e
mudanças de espaço de nomes em coisas que estão funcionando perfeitamente, por que ..?

No domingo, 2 de abril de 2017 às 14:04, Adam Ralph [email protected] escreveu:

👍 para alterar o namespace raiz para AutoFixture em uma versão de última hora.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

Eu concordo com a análise geral (os prós e contras descritos acima).

Como já foi observado por várias pessoas aqui, alterar o namespace seria uma alteração significativa. OTOH, alterar o namespace entre a versão 3 e a versão 4 parece pelo menos defensável, devido à mudança na governança. Seria muito mais difícil defender a remoção de 'Ploeh' entre a versão 4 e a versão 5.

Se você deseja remover 'Ploeh' do namespace, agora é a hora de fazê-lo.

@ploeh Obrigado pela resposta. Mais uma pergunta para você - qual opção você prefere pessoalmente? :) Sei que essa é uma pergunta um pouco complicada, mas acredito que não sou o único para quem isso importa, já que você é um fundador (ou cofundador, não tenho certeza: flushed :).

Eu prefiro que você tome a decisão que você acredita ser a melhor para o projeto em andamento 😉

De uma perspectiva externa, posso dizer que ter o namespace Ploeh.Autofixture tornou meu primeiro uso da biblioteca um pouco mais difícil porque o namespace não está relacionado ao nome do pacote ou ao projeto aqui no GitHub.

É uma espécie de surpresa digitar using Auto... e receber uma lista vazia do Intellisense.

Eu concordo com @Kralizek.
Mas o problema de renomear o projeto para Fixture.Net (embora pessoalmente eu apoiasse essa etapa) significaria romper com o nome da comunidade .NET bem amplo e bem conhecido.

Concordo com o que @ploeh escreveu

Se você deseja remover 'Ploeh' do namespace, agora é a hora de fazê-lo.

Claro, isso só pode acontecer no ramo v4 .

A mudança de namespace é bastante fácil, Search & Replace e você é feito em seu próprio código-fonte.

O problema é com o nuget se outros pacotes estiverem usando o AutoFixture e não tiverem o delimitador de versão correto no nuspec, então isso também será interrompido. Mas, por enquanto, o usuário pode facilmente voltar ao AutoFixture 3.x. Isso pode ser abordado na Documentação, publicação do Blog de Liberação ou qualquer outra coisa.

Sou a favor de remover Ploeh do namespace, nunca gostaria de nomes pessoais no namespace, fiz isso no início de meus projetos, me odiava por fazer isso;)

se outros pacotes estiverem usando AutoFixture e não tiverem o delimitador de versão correto no nuspec, isso também irá quebrar

Eu não me importaria com isso. O mesmo problema existe para todas as versões mais recentes. Se os pacotes posteriores optaram por não colocar um limite superior exclusivo na próxima versão principal, por exemplo, <dependency id="AutoFixture" version="[3.0,4.0)" /> , então eles estão provocando esse problema toda vez que uma versão principal do AutoFixture é lançada.

@abatishchev Fixture.Net vem de outra discussão? Eu ficaria muito feliz simplesmente mudando o namespace para AutoFixture

@moodmosaic Você também poderia acrescentar sua posição sobre isso? Acredito que precisamos ter todas as opiniões dos principais mantenedores para tomar a decisão final.

Ι já fiz .

@moodmosaic Eu vi essa resposta, mas não tenho certeza se entendi sua posição. Você vota para manter o namespace ou removê-lo? :)

Eu voto por mantê-lo. Menos perturbador.

Por que fazer coisas perturbadoras o preocupa? Muitas pessoas pedem essa mudança.
Ainda menos perturbador seria deixar o projeto como está, sem fazer nenhuma alteração. Mas não é disso que se trata todo esse processo, não é?
Eu, pessoalmente, gostaria de ver você avançando com essa mudança.

@moodmosaic Eu vi essa resposta, mas não tenho certeza se entendi sua posição.

Eu ficaria bem para mim se o namespace raiz fosse renomeado apenas para AutoFixtura em v4 .

Embora eu apoie meu voto anterior para manter o namespace Ploeh , não há problema em removê-lo, se isso é o que a maioria das pessoas deseja.

Dada a mudança de propriedade, vejo como faria sentido para o projeto avançar e o momento é certo. Nesse ponto, os únicos contra-argumentos que posso apresentar baseiam-se exclusivamente nas emoções.

@ecampidoglio , eu estava tendo emoções também, mas acho mais 'correto' com apenas _AutoFixture_ na v4 ...

@moodmosaic Obrigado pela resposta, a mesma coisa realmente acontece comigo. Quanto mais aprendo este projeto, mais vejo e percebo a quantidade de trabalho que Mark fez aqui - grande número de discussões diferentes, pequenos ajustes, respostas no SO, etc. Torna-se cada vez mais difícil tomar a decisão de cortar o prefixo - é parece ingrato em relação a Mark.

Por outro lado, eu entendo que o prefixo AutoFixture simples terá uma aparência muito melhor e consistente. Na verdade, não há nada de horrível aqui, já que o nome de Mark ainda estará presente na lista de autores do pacote, wiki, questões .. Com @adamchester e @ecampidoglio votos para manter o prefixo fica ainda mais difícil tomar a decisão - muitos o material emocional está presente aqui. Provavelmente, devemos separar o aspecto emocional e não confundir as coisas. Pessoalmente, não trato o corte de namespace como um ato de depreciação do trabalho de Mark - para mim, o motivo é puro cuidado de casa. Ainda serei muito grato a ele, mesmo que o prefixo esteja ausente.

No entanto, como comecei a trabalhar no projeto tarde demais (e ninguém me conhece), sinto que não consigo entender totalmente a contribuição do Marcos e, portanto, a palavra final deve ficar definitivamente com os contribuidores principais.

@zvirja Acho que você entendeu mal meu comentário anterior :

Não há problema em removê-lo, se isso é o que a maioria das pessoas deseja.

Então, sim, eu prefiro mantê-lo, mas estou OK com o namespace AutoFixture na v4. 😉

Minha opinião é basicamente a mesma que @ecampidoglio - prefiro manter o namespace como está apenas para evitar interrupções desnecessárias para os usuários, mas estou bem em alterá-lo para apenas AutoFixture na v4.

parece ingrato em relação a Mark.

Não se preocupe com isso. O melhor agradecimento que você pode me dar é para manter o AutoFixture vivo. Se você puder fazer isso, consegui criar algo que é viável por si só. Poucas coisas podem ser mais satisfatórias do que isso.

Obrigado pela resposta, Mark!

Considerando todas as respostas acima e considerando que a equipe principal não se importa em alterar o namespace, adicionarei isso ao escopo da v4.

É mais uma coisa que esqueci de perguntar sobre - nomes de assembléias. Parece que atualmente os nomes dos assemblies começam com o Ploeh também. Se removermos o prefixo do namespace, faz sentido renomear os assemblies também (por exemplo, de Phoeh.AutoFixture.dll para AutoFixture.dll ). Acredito que o NuGet lidará com essa mudança com elegância. A única coisa com que poderíamos nos preocupar é que essa será uma nova identidade de assembly e será impossível realizar o redirecionamento de assembly de v3 para v4.

O que você acha sobre @moodmosaic , @adamchester e @ecampidoglio - você tem objeções em relação à renomeação da assembléia? Parece uma mudança importante, mas não está pronto para avaliar quanto.

Depois que os namespaces forem renomeados na v4, o redirecionamento da associação do assembly para v4 não terá sentido. Por esse motivo, e para ser consistente, acho que faz sentido renomear os assemblies para AutoFixture (. *).

Bom ponto, eu perdi isso. Na verdade, todos os nomes completos de tipo serão diferentes, portanto, o redirecionamento não faz sentido. A menos que @adamchester e @ecampidoglio tenham outras preocupações - vamos mudar os nomes também.

Feito! O namespace "Ploeh" e o prefixo do nome do assembly serão removidos da v4, para que comece com "AutoFixture". Esta mudança permite refletir a propriedade atualizada, pois agora o produto está sendo desenvolvido apenas pela equipe do AutoFixture.

Lembre-se que isso quebra a linha de continuidade no que diz respeito à montagem. Ou seja, o novo pacote não conterá uma nova versão do assembly. Em vez disso, a montagem anterior será removida e substituída por uma montagem completamente nova, com uma nova identidade. Isso significa que coisas como redirecionamentos de ligação não podem funcionar entre o assembly contido no pacote 3.xeo assembly contido no 4.x.

Talvez isso não seja um problema, mas achei que vale a pena ressaltar.

BTW - você verificou o comportamento do NuGet quando o pacote é atualizado? Para projetos de estilo SDK, acho que tudo funcionará bem, já que o projeto contém apenas um elemento <PackageReference> apontando para o pacote em vez de assemblies. Mas com o csproj de estilo antigo, pode valer a pena verificar se o NuGet faz a alteração desejada na referência do assembly, de um assembly para outro.

@adamralph Obrigado por suas preocupações!

Isso significa que coisas como redirecionamentos de ligação não podem funcionar entre o assembly contido no pacote 3.xeo assembly contido no 4.x.

Sim, eu sei disso. No entanto, já alteramos o namespace padrão, o que significa que alteramos a identidade de todos os tipos nos assemblies. Nesse sentido, o redirecionamento de associação de assembly não fará sentido, pois o código não funcionará em nenhum caso sem recompilação e correção de importações. Portanto, acredito que estamos totalmente bem com isso. É uma grande mudança, mas acontecerá apenas uma vez.

BTW - você verificou o comportamento do NuGet quando o pacote é atualizado?

Sim, eu já testei isso e funciona bem. A única coisa que você precisa fazer é executar a substituição de texto para corrigir using Ploeh.AutoFixture em using AutoFixture . Depois que o projeto é compilado com sucesso e os testes são executados com sucesso.

A única coisa que você precisa fazer é executar a substituição de texto para corrigir o uso de Ploeh.AutoFixture para usar a AutoFixtura. Depois que o projeto foi compilado com sucesso e o teste foi executado com sucesso.

Sim, exatamente.