Autofixture: 토론: 'Ploeh' 네임스페이스 접두사

내가 아는 한 대부분의 OSS 프로젝트에는 이름과 동일한 루트 네임스페이스가 있으므로 여기서는 문제가 발생하지 않습니다. 이것은 주요 변경 사항이므로 주 버전을 증가시키기만 하면 됩니다.

👍 브레이킹 버전에서 루트 네임스페이스를 AutoFixture 로 변경합니다.

나는 Ploeh 네임스페이스를 유지하는 것에 신경 쓰지 않습니다. 소유권은 관련이 없으며
완벽하게 작동하는 것들에 대한 네임스페이스 변경, 왜..?

2017년 4월 2일 일요일 14:04 Adam Ralph [email protected]에서 다음과 같이 썼습니다.

👍 브레이킹 버전에서 루트 네임스페이스를 AutoFixture로 변경합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/AutoFixture/AutoFixture/issues/745#issuecomment-290999395 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAwCv_G4V_0nKgVTPpSAOpmMAQ8BMJQ6ks5rr9UpgaJpZM4Mw1jd
.

전반적인 분석에 동의합니다(위에서 설명한 장단점).

여기 여러 사람들이 이미 언급했듯이 네임스페이스를 변경하는 것은 획기적인 변경이 될 것입니다. OTOH, 버전 3과 버전 4 사이의 네임스페이스 변경은 거버넌스 변경으로 인해 최소한 방어 가능한 것으로 보입니다. 버전 4와 버전 5 사이에서 'Ploeh'를 제거하는 것을 방어하는 것이 훨씬 더 어려울 것입니다.

네임스페이스에서 'Ploeh'를 제거하려면 지금이 해야 할 때입니다.

@ploeh 답변 감사합니다. 한 가지 더 질문 - 개인적으로 어떤 옵션을 선호합니까? :) 이것이 약간 까다로운 질문이라는 것을 압니다. 그러나 당신이 설립자(또는 공동 설립자, 확실하지 않습니다 :flushed:)이기 때문에 이것이 중요한 질문이 저 혼자만이 아니라고 믿습니다.

앞으로 나아가는 프로젝트에 최선이라고 생각하는 결정에 도달하는 것을 선호합니다 😉

외부 관점에서 볼 때 네임스페이스가 Ploeh.Autofixture 인 것이 라이브러리의 첫 번째 사용을 약간 어렵게 만들었다는 것을 알 수 있습니다. 네임스페이스가 여기 GitHub의 패키지 이름이나 프로젝트와 관련이 없기 때문입니다.

using Auto... 하고 Intellisense에서 빈 목록을 수신하는 것은 일종의 놀라운 일입니다.

@Kralizek에 동의합니다.
그러나 Fixture.Net으로 프로젝트 이름을 바꾸는 문제(개인적으로는 이 단계를 지원하지만)는 .NET 커뮤니티 이름에서 꽤 광범위하고 잘 알려진 이름을 깨는 것을 의미합니다.

@ploeh가 쓴 내용에 동의

네임스페이스에서 'Ploeh'를 제거하려면 지금이 해야 할 때입니다.

물론 이것은 v4 분기에서만 발생할 수 있습니다.

네임 스페이스 변경은 다소 쉽고 검색 및 바꾸기이며 자체 소스 코드에서 수행됩니다.

문제는 다른 패키지가 AutoFixture를 사용하고 있고 nuspec에 올바른 버전 구분 기호가 없는 경우 nuget과 관련된 것입니다. 그러면 이것도 중단됩니다. 그러나 당분간 사용자는 AutoFixture 3.x로 쉽게 돌아갈 수 있습니다. 이것은 문서, 릴리스 블로그 게시물 등에서 해결할 수 있습니다.

나는 네임스페이스에서 Ploeh를 제거하기 위한 것입니다. 네임스페이스에서 개인 이름을 원하지 않습니다. 내 프로젝트 초기에 이 작업을 수행했고, 그렇게 하는 것이 싫었습니다. ;)

다른 패키지가 AutoFixture를 사용하고 있고 nuspec에 올바른 버전 구분 기호가 없는 경우에도 중단됩니다.

나는 그것에 대해 걱정하지 않을 것입니다. 모든 브레이킹 버전에 대해 동일한 문제가 존재합니다. 다운스트림 패키지가 다음 주요 버전(예: <dependency id="AutoFixture" version="[3.0,4.0)" /> 에 독점적인 상한선을 두지 않도록 선택한 경우 AutoFixture의 주요 버전이 릴리스될 때마다 이 문제가 발생합니다.

@abatishchev Fixture.Net 는 다른 토론에서 나온 것입니까? 네임스페이스를 AutoFixture 변경하기

@moodmosaic 이에 대한 귀하의 입장도 추가해 주시겠습니까? 최종 결정을 내리기 위해서는 모든 핵심 관리자의 의견이 필요하다고 생각합니다.

Ι 는 이미 했습니다.

@moodmosaic 그 답변을 보았지만 귀하의 입장이 확실하지 않습니다. 네임스페이스를 유지하거나 제거하는 데 투표하십니까? :)

나는 그것을 유지하기 위해 투표합니다. 방해가 적습니다.

방해가 되는 일을 하는 것이 걱정되는 이유는 무엇입니까? 많은 사람들이 이러한 변경을 요구합니다.
덜 방해가 되는 것은 프로젝트를 그대로 두고 전혀 변경하지 않는 것입니다. 하지만 이 모든 과정은 그게 아니잖아요?
나는 개인적으로 당신이 이 변화를 진행하는 것을 보고 싶습니다.

@moodmosaic 그 답변을 보았지만 귀하의 입장이 확실하지 않습니다.

루트 네임스페이스가 v4 AutoFixture 로 이름이

Ploeh 네임스페이스를 유지하는 것에 대한 이전 투표 를

소유권의 변경을 감안할 때 앞으로 진행 중인 프로젝트와 적절한 시기가 어떻게 의미가 있는지 알 수 있습니다. 이 시점에서 내가 생각할 수 있는 유일한 반론은 오로지 감정에 근거합니다.

@ecampidoglio , 나도 감정이 있었지만 v4에서 _AutoFixture_만으로 더 '정확'한 것 같아요...

@moodmosaic 답변 감사합니다. 같은 일이 실제로 발생합니다. 이 프로젝트를 더 많이 배울수록 Mark가 여기서 수행한 작업의 양을 더 많이 보고 깨닫습니다. 수많은 다양한 토론, 사소한 조정, SO에 대한 답변 등. 접두사를 다듬는 결정을 내리는 것이 점점 더 어려워집니다. 마크에 대해 감사하지 않은 것처럼 보입니다.

다른 측면에서는 간단한 AutoFixture 접두사가 훨씬 더 좋고 일관적으로 보일 것이라는 점을 이해합니다. 사실,이 마크의 이름은 아직 결정하게조차 어려워진다 접두사를 유지하기 위해 @adamchester 및 @ecampidoglio 투표로 .. 패키지 저자, 위키, 문제의 목록에 표시되는 바와 같이, 여기에 끔찍한 아무것도 - 많은의를 감정적인 것들이 여기에 존재합니다. 아마도 감정적인 부분을 분리하고 혼동하지 않도록 해야 할 것입니다. 개인적으로 저는 네임스페이스 트리밍을 Mark의 작업에 대한 감가상각 행위로 취급하지 않습니다. 그 이유는 순수한 가사 때문입니다. 접두사가 없어도 나는 여전히 그에게 매우 감사 할 것입니다.

그러나 내가 프로젝트 작업을 너무 늦게 시작했다는 것을 감안할 때(아무도 나를 알지 못합니다) Mark의 기여를 완전히 이해할 수 없으며 따라서 최종 단어는 확실히 핵심 기여자에게 달려 있어야 합니다.

@zvirja 나는 당신이 내 이전 의견 을 잘못 이해했다고 생각합니다.

그것이 대부분의 사람들이 원하는 것이라면 나는 그것을 제거하는 것이 좋습니다.

예, 유지하고 싶지만 v4의 AutoFixture 네임스페이스는 괜찮습니다. 😉

내 의견은 기본적으로 @ecampidoglio 와 같습니다. 사용자에게 불필요한 혼란을 피하기 위해서만 네임스페이스를 그대로 유지하고 싶지만 v4에서 AutoFixture 로 변경해도 괜찮습니다.

그것은 Mark에 대해 감사하지 않은 것처럼 보입니다.

걱정하지 마세요. 당신이 나에게 줄 수 있는 최고의 감사는 AutoFixture를 계속 유지하는 것입니다. 당신이 그렇게 할 수 있다면, 나는 그 자체로 실행 가능한 것을 만드는 데 성공했습니다. 이보다 더 만족스러운 일은 거의 없을 것입니다.

답변 감사합니다, 마크!

위의 모든 답변과 핵심 팀이 네임스페이스 변경에 신경 쓰지 않는다는 점을 감안하면 v4 범위에 추가하겠습니다.

어셈블리 이름에 대해 묻기 위해 간과 한 것이 하나 더 있습니다. 현재 어셈블리 이름도 Ploeh로 시작하는 것으로 보입니다. 네임스페이스 접두사를 제거하면 어셈블리의 이름도 바꾸는 것이 좋습니다(예: Phoeh.AutoFixture.dll 에서 AutoFixture.dll ). NuGet이 이 변경 사항을 정상적으로 처리할 것이라고 믿습니다. 우리가 걱정할 수 있는 유일한 것은 이것이 새로운 어셈블리 ID가 되고 v3에서 v4로 어셈블리 리디렉션을 수행하는 것이 불가능하다는 것입니다.

@moodmosaic , @adamchester 및 @ecampidoglio - 어셈블리 이름 변경에 대해 이의가 있습니까? 중요한 변화처럼 보이지만 얼마만큼을 평가할 준비가 되지 않았습니다.

v4에서 네임스페이스의 이름이 바뀌면 v4 로의 어셈블리 바인딩 리디렉션은 의미가 없습니다. 이러한 이유로 그리고 일관성을 위해 어셈블리 이름을 AutoFixture(.*)로 바꾸는 것이 합리적이라고 생각합니다.

좋은 지적, 나는 그것을 놓쳤다. 실제로 모든 유형의 전체 이름은 다르므로 리디렉션이 의미가 없습니다. @adamchester 와 @ecampidoglio 가 다른 문제가 없다면 이름도 변경합시다.

완료! "Ploeh" 네임스페이스 및 어셈블리 이름 접두사는 v4에서 제거되어 대신 "AutoFixture"로 시작됩니다. 이 변경을 통해 현재 제품은 AutoFixture 팀에서만 개발되고 있으므로 업데이트된 소유권을 반영할 수 있습니다.

이것은 어셈블리에 관한 한 연속성의 선을 깨는 것임을 명심하십시오. 즉, 새 패키지에는 새 버전의 어셈블리가 포함되지 않습니다. 오히려 이전 어셈블리가 제거되고 새로운 ID를 가진 완전히 새로운 어셈블리로 대체됩니다. 이는 바인딩 리디렉션과 같은 것이 패키지 3.x에 포함된 어셈블리와 4.x에 포함된 어셈블리 간에 작동하도록 만들 수 없음을 의미합니다.

아마도 이것은 문제가 아니지만 지적할 가치가 있다고 생각했습니다.

BTW - 패키지가 업그레이드될 때 NuGet의 동작을 확인했습니까? SDK 스타일 프로젝트의 경우 프로젝트에 어셈블리가 아닌 패키지를 가리키는 <PackageReference> 요소만 포함되어 있기 때문에 모든 것이 잘 작동할 것이라고 생각합니다. 그러나 이전 스타일의 csproj를 사용하면 NuGet이 한 어셈블리에서 다른 어셈블리로 어셈블리 참조를 원하는 대로 변경하는지 확인하는 것이 좋습니다.

@adamralph 걱정 해주셔서 감사합니다!

이는 바인딩 리디렉션과 같은 것이 패키지 3.x에 포함된 어셈블리와 4.x에 포함된 어셈블리 간에 작동하도록 만들 수 없음을 의미합니다.

네, 압니다. 그러나 이미 기본 네임스페이스를 변경했습니다. 즉, 어셈블리 내의 모든 형식에 대한 ID가 변경되었습니다. 이 가벼운 어셈블리 바인딩 리디렉션은 재컴파일 및 가져오기 수정 없이는 어떤 경우에도 코드가 작동하지 않으므로 의미가 없습니다. 그러므로 나는 우리가 그것에 대해 완전히 괜찮다고 믿습니다. 엄청난 변화지만 한 번만 일어날 것입니다.

BTW - 패키지가 업그레이드될 때 NuGet의 동작을 확인했습니까?

예, 이미 테스트했으며 잘 작동합니다. using Ploeh.AutoFixture 를 using AutoFixture 로 수정하기 위해 텍스트 바꾸기를 실행하기만 하면 됩니다. 해당 프로젝트가 성공적으로 컴파일되고 테스트가 성공적으로 실행되면.

당신이해야 할 유일한 일은 AutoFixture를 사용하기 위해 Ploeh.AutoFixture를 사용하는 것을 수정하기 위해 텍스트 바꾸기를 실행하는 것입니다. 해당 프로젝트가 성공적으로 컴파일되고 테스트가 성공적으로 실행된 후.

네, 맞습니다.