Nunit: 기존 Chocolatey 프레임워크 패키지 지원 중단

나에게 좋은 소리. 초콜릿 같은(그리고 너겟) 철학을 유지하기 위해 여러 패키지로 분할되어야 하며 아마도 종속성이 있어야 한다고 생각합니다. 콘솔 러너 플러스 엔진을 위한 좋은 초콜릿 설치가 있다면 동등한 nuget 패키지를 삭제하는 것을 고려할 것입니다.

이것은 수행되어야 하지만, 초콜릿 설치는 본질적으로 다른 설치를 래핑하므로 구현은 우리가 지원하는 다른 설치를 결정할 때까지 기다려야 합니다.

@CharliePoole , 나는 이것에 관심이 있고 구현에 대한 몇 가지 질문이 있습니다.

• bin 및 Windows 설치 프로그램 외에 NUnit은 어떤 다른 설치를 고려하고 있습니까?
• 의미론적 방식의 NUnit 버전이 있기 때문에 그룹이 여러 개의 다른 패키지를 출시하는 대신 Chocolatey 패키지 버전을 동기화 상태로 유지해도 괜찮을까요?
• NUnit의 Chocolatey 패키지에 엔진과 콘솔 러너가 모두 포함되어야 한다는 것이 맞습니까?

감사 해요!

@DustinVenegas 이 리포지토리는 NUnit 2.x에서 실질적으로 다시 작성된 NUnit 3.0용입니다. 초콜릿 용도로 새 제품으로 취급할 수도 있습니다. 아직 결정되지 않았습니다.

NUnit 2.6.4용 초콜릿 패키지를 발행할 예정이며, 이는 2.6.3용으로 이미 존재하는 것과 거의 유사합니다.

메이저 버전의 경우 변경될 수 있습니다. 우리는 일반적으로 상호 관련된 작은 패키지를 선호하여 모든 것을 설치하는 대규모 설치 프로그램에서 벗어나려고 노력하고 있습니다. 거의 적절한 패키징 스타일입니다..

귀하의 질문에 대한 답변:

• 초콜릿 외에도 바이너리 zip, Windows 설치 프로그램 및 Nuget 패키지가 있습니다. 아직 GUI가 없지만 만들 때 별도로 포장할 예정입니다. 현재 베타에서 볼 수 있는 패키지는 확실히 최종 단어가 아닙니다. 일부는 분할될 수 있고 새 패키지는 확실히 추가될 것입니다.
• "Chocolatey 패키지를 동기화 상태로 유지"한다는 말이 무슨 뜻인지 잘 모르겠습니다. 3.0 패키징이 현재 존재하는 것과 일치하지 않을 가능성이 큽니다. 아직 이 문제에 대해 작업하지 않은 한 가지 이유는 생성할 바이너리 드롭 및 msis를 확정하지 않았기 때문입니다. 원래 개념에서 콘솔, 엔진 및 프레임워크는 완전히 분리되어 있었습니다. 디자인의 이 단계에서 작업하기가 훨씬 쉽기 때문에 지금까지 베타를 통해 함께 유지했습니다. 우리가 몇 가지 장애물을 극복할 수만 있다면 그것들은 별도로 버전화되고 릴리스될 예정입니다.
• 귀하의 마지막 질문에 대한 답변은 "상황에 따라 다릅니다."입니다. :-)

나는 여전히 초콜릿에 대해 무지하다. 2.6.4 패키지 작업을 통해 이를 알게 되기를 바랍니다. 나는 그것이 단순히 다른 사람들을 끌어들이는 패키지인 메타 패키지를 지원한다고 들었습니다. 가상 패키지(예: 하나 이상의 실제 패키지로 충족될 수 있는 종속성)도 지원합니까?

@찰리풀 ,

NUnit 패키지는 가상 패키지가 되어야 합니다. 포터블 패키지는 "bin deploy"에 대한 Chocolatey 명명법입니다. 설치 패키지는 덮개 아래에 있는 Windows 설치 프로그램을 나타냅니다.

나는 Chocolatey에서 별도의 NUnit3 패키지를 만드는 것을 _권장하지 않습니다_. 그렇게 하면 사용자는 "nunit" 패키지에 의존하여 2x 시리즈를 설치하고 "nunit3"에 의존하여 최신 버전을 설치합니다. 사용자는 semver에 쉽고 안정적으로 의존할 수 있습니다.

내가 설치하고 싶다면...

• NUnit2: choco install nunit -버전 2.*
• 최신 NUnit: choco install nunit
• 특정 NUni3: choco install nunit -version 3.0.0-beta.1

오른쪽. 그러나 설치되는 기본 패키지가 NUnit 2.x와 동일한 구조를 따르는 경우에만 작동합니다. 예를 들어 참조할 만능 Windows 설치 프로그램이 없다면 Chocolatey에는 그러한 패키지가 있을 수 없습니다.

NUnit 3.0은 NUnit 2.x와 완전히 하위 호환되지 않기 때문에 설계상 사용자가 언제든지 자동 업그레이드를 받는 것은 좋지 않은 생각인 것 같습니다.

즉,
1) NUnit 3.0의 기본 패키지 구조가 무엇인지 알고 있습니다.
2) 나는 실제로 Chocolatey에 대해 더 많이 알고 있다. :-)

본질적으로 이것이 3.0 이정표에 있는 이유입니다. 즉, 모든 베타가 완료될 때까지 이를 수행할 계획이 없습니다.

우리는 여전히 이것을 하고 싶습니까?

nunit.org를 스크랩하면 현재 패키지가 자동으로 수집되는 것 같습니다. (우연히 3.4.1에서 고장났고, nunit.org/download 페이지가 항상 GitHub에 링크되었습니까, 아니면 새 페이지입니까?) 피드로 사용하면 피할 수 있는 것 같습니다.

현재 3개의 nunit 패키지가 있고 ~15,000 다운로드가 있으므로 상당한 양의 사용이 이루어지고 있습니다. 설치 프로그램이 새 리포지토리에 있는 후 살펴보는 것이 좋지 않을까요?

@ChrisMaddock Chocolatey는 자동화된 프로세스를 사용하여 생산하는 것을 생산합니다. 나는 그것이 우리 웹사이트를 스크랩하고 있다는 것을 결코 깨닫지 못했습니다. 쉽게 깨질 수 있는 접근 방식처럼 들립니다. 방금 다운로드 페이지를 변경했기 때문에 페이지가 깨져도 놀랍지 않습니다.

나는 초콜릿 포장을 하는 사람들과 함께 뭔가를 하려고 노력했고 사실 그들은 나를 포장업자 중 하나로 추가했습니다. 나는 그것이 우리에게 최소한의 영향을 줄 것이고 궁극적으로 우리 스스로 초콜릿 포장을 할 수 있다고 느꼈습니다. 그들은 우리가 그것을 제거할 것이라고 당시에 그들에게 말했음에도 불구하고, 그러나 msi를 계속 패키지합니다.

오픈 소스 리눅스 세계에서 패키지 제작자는 사용자가 원하는 대로 하고 업스트림 개발자는 이에 대해 별로 말하지 않는 것이 일반적입니다. 초콜릿을 좋아하는 사람들이 그 구조를 Windows에도 가져오는 것처럼 보였습니다.

하지만 내가 너무 쉽게 포기한 것일 수도 있다. 이 문제를 자신에게 할당하고 시도해 볼 수 있습니다.

추신: V2 및 V3 msis라는 두 가지 패키지만 알고 있습니다. 세 번째는 무엇입니까?

나는 V2와 V3 msis의 두 가지 패키지만 알고 있다. 세 번째는 무엇입니까?

그들은 현재 msi, .zip(더 이상 사용하지 않음) 및 "메타 패키지"를 패키징하며, 이는 "NUnit"("NUnit(설치)"와 반대)이라는 이름으로 msi를 가리킵니다. 이들은 모두 버전 2.6.4 및 3.X에서 사용할 수 있습니다.

나는 우리가 이 두 가지를 모두 계속해야 한다고 생각합니다. msi가 아니라면 계속해서 일종의 설치 프로그램이 있을 것이라고 가정합니다. zip은 엔진/콘솔/추가 기능을 포함할 수 있습니다. 즉, 설치 프로그램이 무엇을 설치할까요? NuGet은 프레임워크의 주요 배포판으로 남아 있음을 의미합니다.

알겠습니다. 내용은 변경되지만 zip을 중지하지는 않습니다.

내 견해는 우리가 초콜릿을 위해 특별한 것을 포장하지 않는다는 것입니다. 우리는 사용자가 필요로 하는 콤보를 파악하고 해당 패키지를 만듭니다. 사용자가 순전히 습관에서 특정 패키지 유형을 원할 때 약간만 뒤로 물러나면 됩니다. 나는 결합된 프레임워크와 러너가 "nunit 시작하기" 패키지의 경우를 제외하고 그런 것들 중 하나라고 생각합니다.

우리에게 중요한 것은 초콜릿을 좋아하는 사람들이 인식한 것과 동일한 것을 인식하는 것입니다. 패키징 번들은 처음부터 소프트웨어를 개발하는 것과 다르며 개별적으로 수행하는 것이 가장 좋습니다.

초콜릿은 NuGet을 기반으로 하지 않습니까? 스크립트 대신 NUnit NuGet 패키지 중 하나를 사용하는 것이 합리적이지 않습니까? 면책 조항, 나는 Chocolatey에 대해 거의 아는 것이 없습니다. :눈짓:

우리가 초콜릿을 좋아하는 사람들이 하는 일에 영향을 줄 수 없다면 그것은 모두 매우 학문적입니다.

초콜릿 패키지는 독립적인 설치 스크립트가 다르기 때문에 다르게 패키징해야 한다고 생각합니다. (기본적으로 생성된 파일이 우리가 필요로 하는 모든 작업을 수행할 것이라고 가정하고 확인해야 합니다.) 그러나 그들은 nuspec 파일을 사용하므로 이를 공유하고 초콜릿을 위한 몇 가지 추가 기능을 추가할 수 있습니다.

좋은 점은 휴대용 버전의 내용이 NUnit.Runners NuGet 패키지를 반영했다면 좋았을 것입니다. 추적할 항목이 줄어듭니다!

이 이후로 몇 가지 작은 메모가 1년 이상되었습니다.

휴대용(bin 설치) 및 전체 NUnit 패키지는 패키지에 포함된 .zip/.msi 또는 패키지를 다운로드하기 위한 영구 URL을 사용하여 Chocolatey용으로 패키지될 수 있습니다. 다른 프로젝트에서는 Github 릴리스 URL을 사용하여 적절한 패키지를 동적으로 다운로드했습니다.

@CharliePoole 에게 nunit 패키지가 메타패키지인 경우 Chocolatey는 자동으로 아무 것도 업데이트하지 않습니다. 사용자는 패키지를 최신 버전으로 맹목적으로 업데이트하거나 packages.config 파일을 만들고 패키지의 특정 _versions_가 설치되도록 지정해야 합니다.

다른 패키지가 설치된 NUnit의 모든 버전에 의존할 수 있고 개별 버전에 대한 특정 패키지를 가질 수 있도록 여전히 NUnit 메타패키지를 권장합니다. 이것은 apt-get/brew install nodejs를 사용하는 것과 다르지 않으며 필요한 특정 버전을 지정하는 대신 최신 버전을 설치합니다.

@DustinVenegas 휴대용 패키지와 전체 패키지가 무엇을 의미하는지 잘 모르겠습니다. 이식 가능한 프레임워크 빌드가 있지만 다른 빌드와 별도로 패키징되지 않습니다. Silverlight 및 컴팩트 프레임워크만 별도의 패키지로 제공됩니다. 나는 그들이 github URL을 사용하여 패키지를 가져와야 한다는 데 확실히 동의합니다. 웹사이트 페이지는 항상 변경될 수 있습니다. 그러나 우리가 통제할 수 없기 때문에 "그들"이라고 말합니다.

나는 메타 패키지가 갈 길이라는 데 동의하지만 우리가 초콜릿 포장을 하지 않기 때문에 다시 약간 통제할 수 없습니다. 나는 우리의 nuget NUnit.Console 패키지를 nuget이 지원하는 한계 내에서 메타패키지의 근사치라고 생각하지만 apt-get 세계에서 메타패키지의 힘과 다를 바가 없습니다.

Chocolatey.org의 사람들과 독립적으로 초콜릿 패키지를 직접 시작할 수 있는 방법이 있습니까?

@CharliePoole - Chocolatey는 설치 프로그램이 없는 패키지를 .NET 휴대용과 관련이 없는 휴대용으로 참조합니다. 현재 nunit.portable 패키지는 msi인 nunit.install 와 달리 .zip NUnit 릴리스입니다.

Chocolatey.org는 일반적으로 소프트웨어 공급업체가 자체 패키지를 유지 관리하기를 열망하는 것 같습니다. 따라서 기존 패키지를 대체할 수 있는 작업을 할 수 있기를 바랍니다. 귀하의 경험에 따르면 예상보다 원활하지 않을 수도 있습니다. #1716이 완성된 후에 연락할 계획이었고 지금은 내가 자리를 비운 후일 것입니다. 그러나 누군가가 더 빨리 이 작업을 수행하고 싶다면 인수할 수 있습니다. :웃다:

다른 패키지가 모든 버전의 NUnit에 의존할 수 있도록 여전히 NUnit 메타패키지를 권장합니다.

@DustinVenegas - 여기서 의미하는 바를 명확히 할 수 있습니까? 아래 링크는 현재 NUnit 메타 패키지(초콜릿 녀석들에 의해)입니다. 제 보기에는 설치 프로그램 패키지의 특정 버전을 통과하는 것처럼 보입니까? 메타패키지가 nunit.install 가 아닌 "모든 버전에 종속"되도록 허용하는 시점은 무엇입니까?

https://github.com/dtgm/chocolatey-packages/blob/master/automatic/nunit/nunit.nuspec

나도 초콜릿 전문가라고 주장하지 않습니다!

@찰리풀 ,
귀하는 Chocolatey NUnit 패키지 에 등록되어 있습니다. @dtgm 은 상당한 책임이 있으며 PR을 수락하거나 자동 패키지를 모두 중지하도록 요청할 수 있으며 릴리스 프로세스에 포함될 수 있습니다. 나는 카르낙을 위해 비슷한 일을 했습니다. "Contact Site Admins" 또는 Gitter 채널도 물어볼 수 있는 좋은 장소입니다.

@ChrisMaddock ,
메타패키지가 지금 특별한 것을 허용하지 않는다는 것이 맞습니다. Chocolatey는 nunit.portable _또는_ nunit.install이 nunit 종속성을 충족할 수 있도록 하는 "가상 패키지"를 아직 마무리 중입니다. 현재로서는 Chocolatey가 메타패키지 라고 부르는 것을 만드는 것이 이를 준비하는 데 따라야 할 올바른 방법론입니다.

설치 프로그램을 단계적으로 중단 하려는 @dtgm 에 PR을 제출하거나 직접 프로세스를 인수 하는 것이 좋습니다. 메타패키지 nunit 에는 v2 및 v3용 릴리스가 포함되어야 하며 동일한 버전의 nunit.portable 패키지에 종속되어야 합니다. 최종 소비자는 빌드 서버/개발 기계에 대해 쉽게 choco install nunit --version 2.x.x 에 도달합니다. 다른 패키지는 <dependency name="nunit" version="3.x.x" /> 에 의존하게 되며 이는 향후 설치 프로그램이나 휴대용 패키지에 의해 수행될 것입니다.

@DustinVenegas 예... 나는 이것을 인수할 수 있기를 바

분명히 말해서, 나는 기분이 상하지 않았습니다. 이것은 리눅스 세계에서 패키저와 업스트림 개발자 사이에 꽤 흔한 종류의 불일치이므로 여기서 그것을 보는 것은 놀라운 일이 아닙니다.

만약 우리가 Chocolatey를 위한 대안 패키지를 제공할 수 있다면, 다시 논의를 시작해야 할 때라고 생각합니다. 그러한 패키지를 만드는 데 관심이 있는 사람이 이 문제를 해결해야 합니다.

한 가지 요점은... NUnit 2와 3을 모두 포함하는 메타패키지를 만들자는 제안이 잘못된 것 같습니다. NUnit V2 또는 NUnit V3 _둘 중 하나에서_ 충족할 수 있는 요구 사항이 생각나지 않습니다. 인터페이스 수준에서 호환되지 않는 제품입니다. 그러한 메타패키지에 의존할 수 있는 것에 대한 예를 들 수 있습니까?

@찰리풀 ,

Chocolatey 개발자는 매우 환영했습니다. 패키징을 완전히 제어하려면 Gitter의 @ferventcoder 에 연락하거나 관리자에게 문의 링크가 가장

이제 메타패키지에 대해 알아보자. Chocolatey 최종 사용자로서 choco install package 이 패키지의 가장 최신 기본 버전을 설치하기를 기대합니다. 빌드 서버용 자동화 스크립트를 생성하는 경우 최신 2.6 릴리스를 설치하는 nunit-2.6.* 에 종속될 수 있습니다. 패키지를 만드는 중이라면 nunit-3.2.* 또는 더 구체적인 버전에 의존할 수 있습니다.

메타패키지는 (Nuget 패키지)[https://www.nuget.org/packages/NUnit/]와 모양과 기능이 완전히 동일합니다. 여기서 semver는 주요 변경 사항을 표시하기에 충분합니다. nunit.portable v2.0.2 _또는_ nunit.install v2.0.2가 nunit v2.0.2 요구 사항을 충족하는 방법일 뿐입니다. 또한 동일한 패키지의 여러 다른 버전을 동시에 설치할 수 있습니다.

설치 프로그램을 제거하려고 하므로 이동식(bin) 설치를 nunit 패키지에 게시하는 것으로 충분할 수 있습니다. 즉, 현재 내 모든 자동화는 설치 프로그램으로 기본 설정되는 nunit 3.2.1에 의존합니다. 흥미로울 수 있습니다.

@DustinVenegas 제가 말했듯이 그들은 저를 환영했습니다. 우리는 그들이 포장하려는 것에 동의할 수 없었습니다.

나는 이미 당신이 내가 이야기할 것을 제안한 바로 그 사람들과 광범위하게 접촉했습니다. 그들은 그들이 하는 일을 바꾸고 싶지 않다는 것을 분명히 했습니다. 그래서 내가 당신에게 그들의 개입 없이 초콜릿 형태의 패키지를 만드는 것이 가능한지 물었습니다.

나는 당신과 내가 초콜릿을 좋아하는 사람들과 쉽게 일할 수 있다는 데 동의하지 않는 데 동의해야 한다고 생각합니다.

메타패키지와 관련하여 "nunit에 대한 종속성 가져오기"가 의미하는 바에 따라 합리적이라고 생각합니다. v2와 v3 사이에는 공통된 어셈블리 이름이 하나만 있습니다.

그들은 단지 내 충고를 받아들이기를 원하지 않았기 때문에 내 이름을 거기에 두는 것은 순전히 영예로운 일이었습니다. :-)

@CharliePoole은 실제로 귀하가 패키지 출시를 시작하기를 희망하여 귀하를 추가했습니다. 다음은 다른 사람들을 위한 원본 대화입니다 - https://chocolatey.org/packages/nunit#comment -1840892100. 약 1년 전이었습니다. 그 당시에는 NUnit 사람들이 실제로 패키지를 릴리스하거나 @dtgm 에 자동 패키징을 사용하여 버전 릴리스를 중지하도록 요청하는

커뮤니티 리포지토리에서 패키지 릴리스를 계속 진행하고 싶다면 완전히 괜찮습니다. 우리는 이를 매우 환영합니다. 그러나 NuGet과 Chocolatey의 차이점을 이해하는 데 있어 약간 과도하게 생각하고 있을 수 있습니다. 이제 NUnit.Runners를 Chocolatey 패키지로 설치할 수 있습니다. choco install nunit.runners --source https://www.nuget.org/api/v2/ . Chocolatey는 바이너리를 수집하는 방법에 대해 더 많은 기능을 가지고 있지만 패키지 자체에 런타임 바이너리를 포함하는 것만 큼 간단합니다. 일반적으로 소프트웨어 공급업체가 아닌 사람들은 소프트웨어에 대한 배포 권한이 없으며 원격 위치에서 다운로드해야 합니다.

그런데 그 명령의 출력 :

그들은 그들이 하는 일을 바꾸고 싶지 않다는 것을 분명히 했습니다. 그래서 내가 당신에게 그들의 개입 없이 초콜릿 형태의 패키지를 만드는 것이 가능한지 물었습니다.

@CharliePoole 현재 패키지 말하는지 잘 모르겠습니다. 전달된 내용에 대한 잘못된 의사소통 또는 오해인지 확실하지 않습니다. 현재 수행되고 있는 방법에 대한 건전한 대화를 보았고 v3에 대해 어떻게 접근할 것인지에 대한 질문을 보았습니다. - https://chocolatey.org/packages /nunit#comment -2120088484.

3.0과 관련하여 레지스트리에 등록된 이름을 2.x 시리즈와 다른 이름으로 변경하고 싶을 것입니다. 그렇지 않으면 3.0이 동일한 패키지 이름으로 릴리스되어야 합니다. 그렇지 않으면 두 패키지가 공통 레지스트리 이름을 공유해서는 안 되므로 설치/제거 중에 충돌이 발생합니다. 누군가가 이전 버전의 nunit을 설치하려는 경우 항상 '-버전 2.6.4'를 지정하고 '초코 고정'할 수 있습니다.

나는 이것을 별도의 패키지로 v3를 릴리스하거나(이전에 주석에서 무엇을 하고 싶은지를 명시했기 때문에) 현재 "nunit"에서 v3가 발생하도록 하는 방법에 대한 제안으로 읽었습니다. 패키지 및 귀하가 결정을 내리지 않은 경우 어떤 일이 발생하는지.

나는 또한 그 대화만 계속할 수 있기 때문에 현재 유지 관리자가 상황이 바뀌는 것을 보고 싶지 않다는 것이 나중에 분명히 밝혀진 다른 커뮤니케이션이 있었는지 모르겠습니다. 알려주세요?

참고로 저는 잠시 자리를 비웠기 때문에 할당을 해제했고 이것이 움직이기 시작하는 것 같습니다. 뭔가 해결될 수 있기를 바랍니다! :웃다:

@ChrisMaddock 실제로 이것을 차단된 것으로 표시하고 있습니다. 그 이유는 내가 1년 전의 토론에서 내 기억을 새로 고쳤고 Chocolatey 설치는 항상 우리 설치를 기반으로 한다는 것을 깨달았기 때문입니다. 무엇을 패키징하고 출시할지를 확실히 결정할 때까지 패키지 형식을 확산해서는 안 된다고 생각합니다.

패키지 세분성에 대한 결정은 3.0 릴리스 이후 공개되었으며 콘솔/엔진에서 프레임워크를 분할하여 많은 큰 변화를 일으키기 시작했습니다. 어떤 패키지를 초콜릿에 담을 것인지 결정하기 전에 어떤 패키지를 출시할지 목록이 있어야 한다고 생각합니다. 사실, 1년 전의 논의는 주로 우리가 중단할 계획이었고 사실상 중단한 패키지에 대한 초콜릿 릴리스를 원하지 않는 것에 관한 것이었습니다. 그것에 대해서는 별도로 언급하겠습니다.

@DustinVenegas 는 소프트웨어 조각 == 하나의 패키지에 대한 접근 방식을 보고 있다고 생각합니다. 여기서 버전은 패키지의 관심사로 처리됩니다. 소프트웨어가 모든 모양과 크기로 제공되고 다양한 접근 방식을 허용하기 때문에 패키징은 "모든 접근 방식에 맞는 하나의 크기"가 아닙니다.

.NET Framework 2.x 대 .NET Framework 4.x 또는 여러 버전의 Ruby와 같이 동시에 여러 버전을 설치할 수 있는 소프트웨어의 경우 해당 항목에 대해 여러 패키지 이름이 표시됩니다. NUnit v3가 NUnit v2(또는 각각의 여러 버전)와 동시에 시스템에 존재하는 경우 패키징에 대한 여러 접근 방식을 가질 수 있습니다. 여기서 누군가가 동일한 패키지 ID의 여러 버전에 대해 병렬 설치를 사용하도록 하거나, 또는 다른 패키지 이름을 사용합니다. 주요 변경 사항이 다른 패키지 이름을 사용하는 것인지 여부를 말하기는 정말 어렵습니다.

Puppet 및 Puppet-Agent 패키지 - 동일한 소프트웨어, 다른 패키지

고려해야 할 경우는 다음과 같습니다.

• https://chocolatey.org/packages/puppet
• https://chocolatey.org/packages/puppet-agent

꼭두각시 대 꼭두각시 에이전트. 또는 v3까지의 Puppet 및 4.x+의 Puppet을 고려합니다. Puppet 팀은 옴니버스 접근 방식(루비와 모든 도구를 패키지에 번들)으로 전환함에 따라 Puppet-Agent(v4+)용 새 패키지를 만들기로 결정했습니다. 이것은 Windows의 Puppet에 대해 이미 수행되고 있었지만 우리는 모든 OS 플랫폼에서 패키지 이름과 패리티를 유지하기를 원했기 때문에 Chocolatey는 다른 패키지 관리자에 대해 수행된 작업을 따랐습니다.

Ruby - 모든 버전에 대해 동일한 패키지, 그러나 각 주요에 대한 패키지

고려해야 할 또 다른 경우:

• https://chocolatey.org/packages/ruby

ruby 패키지는 현재 모든 것을 함께 묶습니다. 또한 주요 버전(1.9.x, 2.0.0, 2.1.x, 2.3.x 등)별로 Ruby 패키지를 생성하여 Ruby를 설치할 때 더 많은 선택을 할 수 있도록 하는 방법도 생각해 보았습니다. 이것은 또한 다른 OS 플랫폼에서 Ruby에 대한 패키징이 수행되는 방식과 동등합니다.

이 중 하나(또는 다른 것)는 여러분이 할 수 있는 일에 대한 고려 사항이 될 수 있습니다. :)

옵션이 있습니다

내가 말하려는 것은 당신에게 선택권이 있다는 것입니다. 사람들이 현상 유지를 설명할 때, 또는 한 사람이 어떻게 해야 하는지를 말할 때(나일지라도), 그것을 초콜릿 커뮤니티가 변경하고 싶지 않습니다. Chocolatey 커뮤니티에서는 상황이 유동적이고 빠르며 다른 패키지 관리자보다 빠르게 변경 사항을 볼 수 있습니다.

@ferventcoder 안녕하세요 Rob! 나는 당신이 당신의 이름을 "들었"다고 생각합니다. :-)

마지막 게시물 이후로 저는 약 세 곳에서 있었던 모든 토론을 검토했습니다. 오늘의 눈으로 그들을 바라보며 나는 몇 가지를 깨달았다. . .

1. 내가 이야기했던 사람들은 모두 "초콜릿 남자"가 아닙니다. 그들 중 일부는 실제로 커뮤니티 기여자입니다. 당시에는 이것이 명확하지 않았습니다. 특히 900개가 넘는 패키지가 자동으로 출시된 친구가 초콜릿 프로젝트의 일부라는 인상을 받아 계속 하고 싶은 그의 바람을 초콜릿 때문이라고 생각했습니다. 여하튼, 다시 읽으면 방금 클릭했습니다... 초콜릿은 커뮤니티 사람들이 작성자가 아닌 소프트웨어의 릴리스를 패키지화할 수 있도록 합니다! 그것은 아마도 당신의 관점에서 볼 때 분명하지만 이해하지 못했습니다.
2. 공개 토론에 있는지 아니면 별도의 이메일에 있는지 기억이 나지 않지만 유지 관리자와 통신하면서 내가 인수하는 것을 선호하는 NUnit 3용 자동 NUnit 빌드를 계속 릴리스할 의향이 있는지 물었습니다. 그는 자신의 개인 리포지토리에 PR을 제출하도록 나를 초대했지만 그렇게 했다고 말했습니다. 그런 식으로 나를 위해 문제를 닫았습니다. 내가 그를 당시 초콜릿 기반 시설의 일부로 보고 있었기 때문에 부분적으로는 최종적인 것처럼 보였을 수도 있습니다. 그러나 주로 나는 그가 좋든 싫든 우리 라이선스 조건 내에서 자신의 NUnit 패키지를 릴리스할 권리가 있다고 느꼈습니다.
3. 우리는 NUnit 3의 1일째부터 "마스터" nunit msi의 날짜가 지정되었다는 것을 알고 있습니다. 우리는 호환성을 위해 계속 유지하고 있었고 솔직히 말해서 이미 너무 오래 유지했습니다. 이제 없어졌어. NUnit의 다음 버전에 대한 msi가 있지만 프레임워크는 포함되지 않습니다. 나는 이것이 설명해야 할 것이지만 이것이 초콜릿 사용자에게 큰 손실이라고 생각하지 않습니다. 프레임워크는 라이브러리이기 때문에 nuget을 통해 프로젝트별로 프로젝트별로 처리하는 것이 더 낫다고 생각합니다.
4. 당시, 그리고 현재까지 계속해서 커뮤니티 사이트에는 릴리스를 통해 구별되는 NUnit용 패키지가 하나만 포함되어 있다고 생각합니다. 아시다시피, 우리는 NUnit 3를 NUnit 2와 별도의 패키지로 취급하기로 결정했습니다. 단, 프레임워크에 대한 예외는 예외입니다. 두 개의 서로 다른 프로그램을 하나의 패키지로 취급하는 것은 사용자에게 표면적으로는 편리해 보이지만 실제로는 같은 방식으로 작동하지 않을 때 모든 종류의 혼란을 야기합니다. 나는 별도의 NUnit 3 패키지로 인수를 제안했지만 그 제안은 거절된 것 같았다. 글과 이메일을 다시 읽어보니 이해가 잘 안 된 부분이 있었던 것 같습니다.
5. 나는 당신과 현재 관리자 모두 그 1년 간의 토론에서 저를 잘 대해주었다는 것을 다시 강조하고 싶습니다. 내가 약간 옹알이를 하는 것 같다면 내가 처음부터 다시 시작하기를 바라는 것처럼 보이는 댓글 작성자에게 있었습니다.

결론은... 나는 우리가 NUnit 3에 대한 초콜릿 설치를 유지하기를 원한다고 말했습니다. 현재 유지 관리자에게 NUnit 3와 NUnit 2를 할 계획이 있는지 물었습니다. 그는 예라고 대답했고 저는 충돌을 피하기 위해 물러났습니다.

아이러니하게도 @ChrisMaddock 과 @DustinVenegas 가 이에 대해 적극적으로 논평하기 시작했을 때 저는 실제로 이 문제를 정리의 일부로 삭제할 준비가 되어 있었습니다. 이것은 내부적으로 생성된 문제였습니다. 사용자가 choco 설치를 요청하지 않았습니다. OTOH, 나는 도구에 초콜릿을 사용하고 msis를 완전히 삭제하는 아이디어를 좋아하므로 잠시 동안 계속 사용할 수 있습니다.

방금 다른 의견을 받았습니다... 따로 답장드리겠습니다.

@ferventcoder 패키지 대 소프트웨어...

옵션이 보이니 다행입니다. :-)

동일한 패키지의 두 가지 버전을 사용하는 것은 사용자가 두 패키지 모두에서 동일한 전체 기능을 얻는다는 것을 의미해야 한다고 생각합니다. 우리가 항상 잘하지는 않았지만 개선되었으면 합니다.

여기 내 말은 ...

NUnit V2에는 다음을 포함하는 msi가 있습니다.

• nunit 프레임워크의 최신 버전
• NUnit 콘솔 러너
• NUnit GUI 러너
• 프로세스 외부에서 사용된 NUnit 에이전트
• 두 러너가 사용하는 라이브러리

이 패키지를 사용하여 사용자는

• 프레임워크를 참조하여 테스트 작성
• 콘솔 러너에서 테스트 실행
• GUI 러너에서 테스트 실행

NUnit V3에는 다음을 포함하는 msi가 있습니다.

• NUnit 콘솔 러너
• NUnit 엔진(에이전트 포함)

이 패키지를 사용하여 사용자는

• 콘솔 러너에서 테스트 실행
• 엔진을 사용하여 프로그래밍 방식으로 테스트 실행

패키지 이름은 하나지만 사용자에게 새 버전에서는 더 이상 일부 작업을 수행할 수 없지만 수행할 수 있는 다른 작업은 있다고 말하는 것은 다소 어려운 것으로 판명되었습니다.

또는 우리가 일을해야하는 방법이 경우에 - 나는 사람들이 우리가 일을하는 방법을 알려 할 때 너무 많은 마음을 지불하지에 대한 의견을 주셔서 감사합니다. 불행히도 나는 그것을 반대로 적용하고 있었고 포장업자가 내 의견에 주의를 기울이게 할 방법이 없다고 생각했습니다. :-(

우리가 생산할 계획이 있는 패키지를 실제로 확정할 때까지 이 문제에 대해 작업을 수행해서는 안 된다는 이전 진술에 동의하시겠습니까?

우리가 생산할 계획이 있는 패키지를 실제로 확정할 때까지 이 문제에 대해 작업을 수행해서는 안 된다는 이전 진술에 동의하시겠습니까?

나는 그것에 동의합니다. 계획 없이는 앞으로 나아갈 길을 알기 어렵습니다. 👍

우리는 협업 프로세스로 이에 대한 정보를 제공할 수 있고, 대부분 손을 놓고 모든 것이 원하는 작업에 적합한지 확인하거나 궁극적으로 커뮤니티에 패키지를 제출할 수 있으며 거기에서 갈 수 있습니다. 내 추천은 처음 두 가지 접근 방식 중 하나입니다. 패키지와 관련하여 여기에서 무엇을 하고 싶은지 가장 잘 알 수 있을 것입니다.

하나의 종속성 요구 사항 - 초콜릿 프레임워크

패키징과 관련하여 현재 확고한 한 가지는 종속성입니다. 종속성은 DLL 수준이 아니라 응용 프로그램 수준에 대한 응용 프로그램입니다. 각 단위(패키지)에는 사용해야 하는 모든 필수 어셈블리가 포함되어야 합니다. "nunit-agent.exe"가 포함된 "nunit-agent"라는 패키지가 있다고 가정해 보겠습니다. nunit-agent.exe에 nunit.dll이 필요한 경우 nunit.dll도 해당 패키지에 있어야 합니다.

"사용할 필요가 있습니다"라고 말할 때 "아마도 혜택을 볼 것"이 아니라 "실행하기 위해 필요합니다"를 의미한다고 가정합니다.

예를 들어... nunit 프레임워크(패키지 nunit)를 설치하면 테스트를 빌드할 수 있습니다. 이러한 테스트를 실제로 실행하려면 일종의 러너가 필요합니다. 그 주자는 콘솔, GUI, VS 어댑터 또는 직접 작성하는 것일 수 있습니다. 나는 이것을 의존성이라기보다는 "제안"이라고 부를 것이고 나는 초콜릿이 그것을 기록할 것이라고 기대하지 않을 것입니다.

콘솔/엔진 패키지를 설치하는 경우(현재 함께 유지할 계획임) 실행할 테스트를 작성하기 위해 nunit 프레임워크의 일부 버전(여러 버전일 수 있음)이 필요할 수 있지만 필수는 아닙니다. . 다시 말하지만, 나는 초콜릿이 이것을 다룰 것이라고 기대하지 않을 것입니다.

이러한 경우 다른 사람이 작성한 테스트를 실행하거나 다른 곳에서 테스트를 실행하여 실행할 수 있습니다. 무리한 작업이라는 것을 알고 있지만 가능합니다.

OTOH, GUI를 설치한다고 가정해 보겠습니다. GUI를 실행하려면 시스템 어딘가에 있는 nunit 엔진 버전이 필요합니다. 콘솔과 함께 번들로 제공되는 버전은 별도의 엔진 패키지가 있는 경우와 마찬가지로 잘 작동합니다. 그 경우 어떤 관계를 원하십니까?

"사용할 필요가 있습니다"라고 말할 때 "아마도 혜택을 볼 것"이 아니라 "실행하기 위해 필요합니다"를 의미한다고 가정합니다.

예, "실행하기 위해" - 어셈블리 수준 종속성.

OTOH, GUI를 설치한다고 가정해 보겠습니다. GUI를 실행하려면 시스템 어딘가에 있는 nunit 엔진 버전이 필요합니다. 콘솔과 함께 번들로 제공되는 버전은 별도의 엔진 패키지가 있는 경우와 마찬가지로 잘 작동합니다. 그 경우 어떤 관계를 원하십니까?

엔진이 실행 파일인 경우 패키지. 엔진이 DLL인 경우 여기에서 흐릿해지기 시작합니다. 일반적으로 그것은 그것을 필요로 하는 각 패키지에 들어간다는 것을 의미합니다. 여러 패키지에서 log4net을 보는 것은 전례가 없습니다.

기타 고려 사항:

• 콘솔의 엔진 버전이 GUI의 엔진 버전과 다를 수 있습니까?
• 엔진이 실행 가능한 경우 자체적으로 패키지하는 것이 의미가 있습니까? 사람들이 그것을 설치하는 것이 혼란스러울까요?

엔진은 API를 통해 러너가 사용할 수 있는 dll입니다. api는 별도의 어셈블리이며 항상 러너가 필요로 하는 모든 패키지와 함께 제공됩니다. API 어셈블리는 엔진을 찾고 로드하고 사용하는 방법을 알고 있습니다. 따라서 엔진은 서비스(windows) 또는 daimon(linux)과 어렴풋이 유사합니다.

러너는 일반적으로 최소 버전의 엔진이 필요합니다. API에 엔진 로드를 요청할 때 필요한 표현입니다. 또한 엔진의 로컬 엔진 사본을 번들로 제공할 수 있으며 API도 이를 처리할 수 있습니다. 또한 일부 러너는 API 어셈블리의 현재 제한 사항을 해결하기 위해 실제로 엔진을 참조할 수 있습니다. NUnit 3 어댑터가 이를 수행합니다.

dll/exe 이분법은 dll을 사용하는 유일한 방법은 dll을 참조하는 것이라는 가정을 기반으로 한다고 생각합니다. 따라서 진정한 구별은 참조되는 항목과 참조되지 않은 항목 사이에 있을 수 있습니다.

내 생각에는... 초콜릿 패키지로 설치된 Windows 서비스가 있는지, 그리고 어떻게 구성되어 있는지 확인하는 것과 관련이 있을 수 있습니다. 이것은 Windows 서비스가 아니지만 여전히 여러 도구에서 사용할 수 있는 서비스입니다.

@nunit/core-team 지금은 nunit-console 프로젝트에 속하는 것 같아요. NUnit 패키지는 프레임워크 라이브러리일 뿐이며 초콜릿에 적합하지 않습니다. OTOH, nunit-console은 도구이며 초콜릿 패키지를 만들면 사용자가 중앙에서 설치할 수 있습니다.

당신이 동의하거나 합리적인 시간 내에 동의하지 않는다면, 나는 이것을 옮기겠습니다. :웃다:

@CharliePoole - 여기에 속하지 않는다는 데 동의했지만 msi와 휴대용 러너를 확장 패키지와 함께 배포하는 것이 잠재적으로 포함된다는 점을 감안할 때 nunit-distribution에서 구현하는 것이 더 적합하지 않을까요? 어느 쪽이든, 그것은 나를 너무 걱정하지 않습니다!

@ChrisMaddock 각각 msi와 zip을 기반으로 하는 설치 패키지와 이식 가능한 패키지를 수행

그러나 NuGet 패키지를 기반으로 하는 기본 휴대용 패키지를 만들 생각입니다. 패키지는 참조일 뿐이므로 프로젝트 자체에서 쉽게 수행할 수 있습니다. 추가 근거로, 저는 직접 작업하고 싶습니다. 이는 nunit-console 프로젝트에서 더 의미가 있습니다.

@CharliePoole - NuGet 패키지를 재사용할 수 있다면 좋을 것이라는 데 동의합니다. 😄 설치 패키지와 관련하여 해당 패키지에는 15,000-25,000개의 다운로드가 있는 반면 휴대용 패키지의 경우 350회만 다운로드된다는 점에 주목할 가치가 있습니다. (15-25k, 스택 방식이 확실하지 않기 때문에!) 어느 쪽이든 설치 패키지에 대한 수요가 분명히 있다고 생각합니다.

초콜릿을 사용할 때 일반적으로 선호하는 것은 기본적으로 설치 프로그램의 실행을 자동화하는 설치 패키지를 선택하는 것입니다. 그렇게 하면 이전에 수동으로 수행했을 때와 똑같이 소프트웨어가 설치된다는 확신이 생겼습니다. 난장판을 피할 수 있어야합니다. 개인적으로 - 설치 프로그램 패키지가 유지되기를 바랍니다. 그러나 더 세분화된 옵션으로 휴대용 패키지를 얼마나 크게 개선할 수 있는지 알 수 있습니다!

안녕하세요 크리스,

이유는 모르겠지만 @charliePool로 보내진 모든 메시지를 받고 있습니다.
그들은 나를위한 것이 아니므로 Github을 확인하고 싶을 것입니다.

백인

찰리 풀

0203 327 4762 / 07876 773 819
www.stowga.com
21 Dartmouth Street, 런던, SW1H 9BP

2016년 12월 7일 14:49:04 Chris Maddock([email protected])
썼다:

@CharliePoole https://github.com/CharliePoole - 동의하면 좋을 것입니다.
NuGet 패키지를 재사용할 수 있습니다. 😄 설치 패키지와 관련하여 아마도
해당 패키지에 15,000-25,000 다운로드가 있다는 점은 주목할 가치가 있습니다.
휴대용 패키지의 경우 350입니다. (15-25,000, 어떻게 그들이
stack!) 어느 쪽이든, 확실히 설치에 대한 수요가 있다고 생각합니다.
패키지.

초콜릿을 사용할 때 일반적으로 선호하는 것은 설치를 선택하는 것입니다.
기본적으로 설치 프로그램 실행을 자동화하는 패키지 -
그렇게 하면 소프트웨어가
내가 손으로 할 때 이전에 했을 것이고
혼란을 피할 수 있습니다. 개인적으로 - 보고싶다
설치 프로그램 패키지가 유지됩니다. 나는 할 수 있지만 휴대용 패키지는
더 세분화된 옵션으로 크게 개선되었습니다!

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/nunit/nunit/issues/452#issuecomment-265466082 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAvZpiyULPLMUNKYzYxRq-ErjVdvaiSCks5rFsdfgaJpZM4DQJtZ
.

@charliepool github이나 메일 서버가 우리를 혼란스럽게

여러 런던 상점에서 주기적으로 정보를 받는 Gmail의 charlie.poole과 같은 사람인지 궁금합니다. :웃다:

하하 - 내가 될 수 있습니다!

2016년 12월 7일 15:23:20, CharliePoole([email protected])
썼다:

@charliepool https://github.com/charliepool github 또는 메일처럼 보입니다.
서버가 우리를 혼란스럽게 합니다.

내가 받는 Gmail의 charlie.poole과 같은 사람인지 궁금합니다.
다양한 런던 상점에서 정기적으로 정보를 제공합니다. 😄

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/nunit/nunit/issues/452#issuecomment-265475613 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAvZpkMaL8QzLvgmwJSHOJ4VNJ11MOrSks5rFs9fgaJpZM4DQJtZ
.

찰리 풀

0203 327 4762 / 07876 773 819
www.stowga.com
21 Dartmouth Street, 런던, SW1H 9BP
@ctapool https://twitter.com/ctapool @stowga https://medium.com/stowga

사과 찰리와 찰리 - 당분간 @ 사용을 중단하겠습니다!

@ChrisMaddock @rprouse 이것은 잠시 동안 앉아 있었고 이제 나에게 할당된 두 가지 공개 프레임워크 문제 중 하나입니다.

나는 우리가 이미 초콜릿을 통해 nunit-console을 출판했다는 인상을 받았습니다. 그렇지 않습니다. 나는 초콜릿이 어떻게 작동하는지 배우기 위한 연습으로 NUnit 프로젝트 에디터를 출판했고 콘솔로 넘어갈 계획이었지만 다른 것들이 떠올랐다. 사실, 콘솔용 초콜릿 패키지를 만드는 데에는 문제가 없습니다. 이 패키지만 있으면 됩니다.

이 스레드에 대한 방대한 토론이 있으므로 우리가 해야 할 일을 요약하겠습니다...

1. 콘솔용 Chocolatey 패키지를 만듭니다. 콘솔 리포지토리에서 해당 문제를 생성하겠습니다.

2. 어떻게 든 오래된 NUnit 초콜릿 패키지를 구식으로 표시하고 더 이상 유지 관리하지 않습니다. 이 문제로 제어할 수 있습니다.

여기서 할 일만 남은 것은 3.4 이후에 생산을 중단한 패키지를 기반으로 하는 기존 nunit 패키지를 chocolatey에 사용하지 않는 것입니다. 나는 dgtm/chocolatey-packages에 문제를 제기하여 그곳을 정리했으며 더 이상 사용하지 않는 이전 패키지의 새 버전을 게시할 것입니다.

이것이 더 이상 사용되지 않을 때 사용자를 참조할 수 있는 패키지가 있을 때까지 차단됩니다.

@CharliePoole - 프레임워크를 choco에 두지 않기로 명시적으로 결정했다고 생각합니다. 그렇죠? 이 문제를 종료할 수 있습니까?

이 문제의 의미는 우리가 작성하지 않은 기존 초콜릿 패키지를 제거하거나 더 이상 사용하지 않는 것으로 점차 변경되었습니다. 더 이상 사용하지 않는다는 것은 사람들에게 무엇을 사용해야 하는지 알려야 하기 때문입니다. 차단을 해제하고 완료할 수 있는지 확인하기 위해 확인할 수 있습니다.

문제가 원래 말한 것과 반대가 되도록 의미가 변경될 때 혼란스럽다는 것을 인정하지만, 이전 패키지를 더 이상 사용하지 않을 때 패키지를 추가할 __ 것입니다__. 😄

그러나 우리는 이전 패키지를 더 이상 사용하지 않을 때 패키지를 추가할 것입니다.

명확히 하자면, 우리가 초콜릿에 프레임워크 패키지를 추가할 계획이라는 뜻인가요? 그 이후로 NuGet에만 프레임워크를, choco에는 주자만 사용하기로 결정했다고 생각했습니다.

msi를 기반으로 하는 Chocolatey에서 우리가 작성하지 않은 오래된 패키지가 있습니다. nunit.msi를 출시할 때마다 자동으로 생성되기 때문에 오랫동안 업데이트되지 않았습니다. 나는 그것을 업데이트할 권한이 있고 더 이상 사용되지 않는 패키지로 업데이트할 것입니다. 이전 패키지를 삭제하고 싶지 않다면 업데이트하여 모든 코드를 제거하고 사용자에게 사용하지 말라고 지시하면 됩니다. Chocolatey에는 이에 대한 일련의 규칙이 있습니다.

이제 그들이 할 수 있는 일은 nunit-console 또는 nunit-console-runner 패키지를 얻는 것입니다. 문제에 대한 차단이 해당 패키지를 기다리고 있었습니다. 지금 해당 패키지를 가리킬 준비가 되었는지 확인해야 합니다. 나는 우리가 그렇다고 생각하지만 다음 콘솔 릴리스를 기다리고 있을지도 모른다는 약간의 의심이 있습니다.

그래. 나는 당신이 대체 _framework_ 패키지를 계획하고 있다는 뜻이라고 생각했습니다. 이것은 저에게 새로운 소식이었습니다! 😆

혼동을 피하기 위해 제목을 변경했습니다.

검토 후 수행해야 할 작업은 다음과 같습니다.

1. 이전 휴대용 또는 설치 릴리스를 더 이상 사용하지 않는 초콜릿용 최신 nunit-console 패키지를 릴리스하십시오.

2. 프레임워크가 포함되어 있지 않더라도 내용면에서 가장 가까운 nunit-console 릴리스를 참조하여 기존 nunit 패키지를 사용하지 않습니다.

누가 이것을 맡을 위치에 있습니까?

나는 당신이 내 제거를 제안하는 것 같아요?

맙소사, 아니. 로드를 퍼뜨리고 싶었지만 누가 Chocolatey에 액세스할 수 있는지 모르겠습니다. 돌이켜보면 이 문제가 누군가에게 할당되었는지 살펴봤어야 했을 것입니다. 그런 식으로 나는 이것이 당신이 팀에서 하기를 기다리고 있는 일이 아니라는 것을 깨달았을 것입니다.

정보를 요청하는 대신 내가 정말 중요하게 생각하는 것이 무엇인지 말했어야 했습니다. 이 문제를 해결하기 위해 제가 할 수 있는 일이 있습니까?

더 이상 차단되지 않는 것 같아서 라벨을 제거했습니다.

더 이상 패키지 릴리스에 관여하지 않으므로 내 할당도 제거합니다.

@CharliePoole - 내가 볼 수 있는 한(공개적으로!) 귀하의 계정은 조직에서 사용 중단하려는 기존 패키지의 유일한 유지 관리자인 것 같습니다(https://github.com/nunit/nunit/issues/452 #issuecomment-340535303). 다른 사람이 해당 문제에 액세스하지 않고 이 문제를 완료할 수 있을지 확신할 수 없습니다. 이 문제가 열려 있는 동안 @rprouse 도 유지 관리자로 추가해야 합니까?

참고로, 조직에서 유지 관리하는 4개의 엔진 확장도 귀하의 계정 아래 있는 것으로 보입니다. 패키지 릴리스에 대한 참여를 종료하려는 경우 Rob을 동시에 여기에 추가하는 것이 합리적인지 모르겠습니다. (커플 유지에 관심이 없다면?? 😛)

또한 이것은 몇 달 전에 발생했습니다. https://blog.nuget.org/20180417/organizations-on-nuget-org.html

@ChrisMaddock 아! 나는 그것에 대해 잊었다. 다시 한 번 살펴보고 무엇이 가능한지 알아보겠습니다. 누군가를 추가할 수 있는 유지 관리자와 동등한 권리가 있는지 또는 해당 패키지의 원래 유지 관리자에게만 권한이 있는지 여부는 알 수 없습니다. 어쨌든 그에게 묻는 것이 예의일 것입니다. 우리는 그 패키지를 누가 책임져야 하는지 결정해야 할 것입니다. Rob이라면 좀 더 탈중앙화된 NUnit 프로젝트를 향한 움직임은 거의 다 끝난 것 같아요.

나는 또한 확장을 유지하는 유일한 사람이라는 것을 잊었습니다. 나는 마지막 릴리스가 어떻게 처리되었는지 나 자신에게 상기시키기 위해 뒤를 돌아보아야 할 것입니다. 아무도 확장에 대한 프로젝트 리더가 된 적이 없으므로 누가 각각을 마지막으로 출시했는지 확실하지 않습니다. 누군가의 요청에 따라 할 수 있었던 것 같아요.

내가 팀에 남아 특정 프로젝트를 이끌고 싶었지만 원하는 대로 되지 않았다는 것을 이미 알고 계실 거라 생각합니다. 지금까지 그 특정한 다리 아래로 많은 물이 흘렀습니다. 어쨌든, 나는 현재 시점에서 일반적으로 공개되지 않고 팀원들 사이에서 더 많은 논의가 필요하다고 생각합니다.

@jnm2 나는 그것을 눈치 채지 못했습니다. 프로젝트에 사용하겠습니다!

감사합니다 Charlie, 잘 들립니다. 참고로 저는 원래 유지 관리자인 @dtgm 이 현재 그의 방대한 초콜릿 패키지에서 물러났고 @gep13 이 유지 관리를 돕기 위해 믿습니다 .

나는보다 그 메모리가 더 이상 공식 소스 찾을 수 없습니다 이 -하지만 난 꽤 확신 @ gep13 더 명확히 수 있고, 우리가 그의 손 떨어져 몇을하는 행복 할 것입니다!

우리는 그 패키지를 누가 책임져야 하는지 결정해야 할 것입니다. Rob이라면 좀 더 탈중앙화된 NUnit 프로젝트를 향한 움직임은 거의 다 끝난 것 같아요.

나는 장기적으로 우리가 '조직 계정' 책임을 원한다는 데 동의합니다. 단기적으로는 Rob이 이미 한 패키지의 계정이기 때문에 함께 유지하는 것이 합리적일 것 같습니다!

@ChrisMaddock yip , 당신은 이것을 정확히 요약했습니다. 어떤 패키지의 관리자로 추가하고 싶은 계정의 사용자 이름을 알려주시면 처리해 드리겠습니다. @dtgm 은 패키지를 유지 관리하는 데 제공될 수 있는 모든 도움이 감사하게 받아들일 것이라는 점을 분명히 했으며 다른 곳으로 이동된 패키징 파일을 제거하기 위해 그의 저장소에 대한 푸시 액세스 권한이 있습니다. 여기에서 어떻게 진행하고 싶은지 알려주십시오.

감사합니다 게리!

@nunit/framework-team & @CharliePoole - 현재 릴리스를 담당하고 있는 @rprouse의 계정을 거기에 두는 데 동의하지 않는 사람이 있습니까? 미래에 더 '조직 기반'으로 이동할 수 있다는 관점에서요?

@ChrisMaddock 추천할 수 있다면... nunit 계정을 만들고 암호 관리자를 사용하여 팀 내에서 자격 증명을 공유하면 한 개인에게 묶이지 않고 앞으로 패키지를 훨씬 쉽게 유지 관리할 수 있습니다. 이것이 우리가 케이크 패키지로 하는 일입니다. 예를 들면 다음과 같습니다.

https://chocolatey.org/packages/cake.portable

우리 케이크 팀 구성원은 모두 패키지의 유지 관리자이지만 모든 새 패키지 버전을 푸시하는 것은 주요 케이크 빌드 계정입니다. Chocolatey는 NuGet이 최근에 출시한 것과 동일한 조직 개념을 갖고 있지 않지만 위에서 제안한 것이 현재로서는 가장 적합합니다.

Gary에게 감사합니다. 장기적으로 우리가 원하는 위치에 더 가까워진 것 같습니다!

@nunit/framework-team & @CharliePoole - 위의 Gary의 제안에 반대하는 사람이 있습니까? 나는 이것을 실현하기 위해 다리 작업을 하게 되어 기쁩니다. 😄

@ChrisMaddock 도움이 필요

@ChrisMaddock 초콜릿과 함께 사용할 nunit 계정을 만드는 것이 좋은 방향이 될 수 있습니다. 패키지 관리자와 저작권 소유자가 동일인이었기 때문에 신뢰할 수 있는 패키지 상태를 얻었지만 실제로 확장할 수는 없습니다. 일단 설정되면 모든 패키지에 사용해야 합니다.

그러나 이 특정 패키지에 nunit을 추가하는 것은 더 이상 릴리스하는 패키지가 아니기 때문에 필요하지 않습니다. 우리는 느슨한 끝을 묶으려고 노력하고 있습니다.

@gep13 이 문제는 오래전부터 있어온 문제

TL;DR 자동으로 생성된 nunit 패키지는 더 이상 생성되지 않아야 합니다. 해당 패키지의 모듈 조합은 더 이상 존재하지 않으며 다른 패키지 이름으로 대체되었습니다. NUnit 프로젝트는 이미 해당 패키지의 초콜릿 버전을 직접 생산하고 있습니다.

이에 대한 논의는 dtgm/chocolatey-packages#310에서 계속하겠습니다.

@CharliePoole - 다른 문제를 만들어 주셔서 감사합니다.

보관하려는 패키지와 관련하여 조직 계정 설정을 제가 처리해 주시겠습니까? 유지 관리자로 추가하려면 귀하의 조치가 필요하지만 귀하가 이 문제를 넘겨주려고 했기 때문에 저는 기꺼이 다리 작업을 수행하게 되어 기쁩니다!

@ChrisMaddock 오래전 에 문제를 생성했지만 프로젝트에 큰 백로그가 있는 것 같습니다. 이 문제의 작업은 실제로 거기에서 완료될 것이라고 생각합니다.

앞으로는 팀이 nunit 계정을 원하는지 아니면 누가 개별적으로 계정을 수행하는지 추적하는 것을 선호하는지 알아보는 것이 좋습니다. 추가해야 할 사람을 추가하고 나중에 나를 제거하게 되어 기쁩니다. 하지만 팀 또는 팀 리더의 결정이라고 생각합니다.

WRT 4개의 확장 프로그램에는 팀도 리드도 없기 때문에 아무것도 하지 않았습니다. 팀시티 확장에만 담당자가 있습니다.

FWIW 나는 한 지점에서 일부 확장을 분기하는 것을 고려했으며 내가 의존하는 확장이 유지 관리자를 얻지 못하면 그렇게 할 수 있습니다.

앞으로는 팀이 nunit 계정을 원하는지 아니면 누가 개별적으로 계정을 수행하는지 추적하는 것을 선호하는지 알아보는 것이 좋습니다. 추가해야 할 사람을 추가하고 나중에 나를 제거하게 되어 기쁩니다. 하지만 팀 또는 팀 리더의 결정이라고 생각합니다.

죄송합니다. 제가 앞서가고 있습니다. @nunit/framework-team의 답변을 기다리겠습니다.

유연성을 위해 조직 계정을 선호합니다.

@ChrisMaddock 문제 없습니다. 내 자신의 기본 설정(존재하는 경우)은 GitHub 자체에 있는 것처럼 여러 사용자 ID가 있는 조직 계정입니다. 사용할 수 없다는 것은 공유 ID가 가야 할 길인 것 같습니다.

나도 조직 계정이 좋다. @gep13 설정이 완료 되면 정보를 [email protected]로 이메일로 보내주시겠습니까? 또는 트위터 @rprouse로 DM주세요.

나에게 할당하는 것이 중앙 집중화로 돌아가고 있다는 @CharliePoole 의 의견에 동의합니다. NUnit 조직의 모든 면을 관리하고 싶지도 않고 시간도 없지만 해야할 동안 업데이트를 업로드하겠습니다 😄

@ChrisMaddock 조직 계정을 관리자로 추가해야 하는 Chocolatey 패키지 목록이 있습니까? 나는 이 부분을 유지하는 일에서 물러났고 전체 그림을 가지고 있지 않습니다. 나는 사용할 조직 계정에 대한 정보를 가지고 @gep13에 연락했습니다. 우리는 그것을 적용할 패키지만 필요합니다.

내가 잘못 이해했을 수도 있지만 우리 중 하나가 nunit 계정을 만드는 것 같습니다. o 이해하는 바와 같이, 그것은 단지 사용자 ID이며 우리가 그것을 그대로 사용한다는 의미에서 "조직적"일 뿐입니다.

저도 잘못 이해했을 수 있습니다. 나는 이것을 위해 사용하는 일반적인 Gmail 주소 중 하나를 @gep13으로 보냈습니다. @gep13 내가 설정해야 하고 유지 관리자로 추가해야 하는 경우

@ChrisMaddock 조직 계정을 관리자로 추가해야 하는 Chocolatey 패키지 목록이 있습니까?

아니요. 하지만 다음에 컴퓨터를 할 때 그런 목록을 만들 수 있습니다. 😊

@rprouse 우리가 사용하지 않는 패키지는 우리가 유지 관리하는 패키지가 아닙니다. 그것은 나를 추가한 @dtgm에 의해 유지 관리되었으며 다운로드 페이지에 새로운 nunit.msi 또는 zip이 나타날 때마다 자동으로 생성되었습니다. 우리는 더 이상 해당 패키지를 생산하지 않습니다.

더 이상 사용하지 않는 이유는 해당 패키지의 모든 사용자가 무엇을 해야 하는지 알 수 있기 때문입니다. 그들이 여전히 그것을 사용한다면 3.4에서 막히므로 많지 않기를 바랍니다.

우리가 ( @ferventcoder 도

nunit org ID는 업로드하지 않을 것이기 때문에 이 패키지가 아닌 유지 관리하는 패키지에 추가해야 합니다.

😢 초코의 오프라인 - 패키지 목록은 추후 공개됩니다!

다음은 우리가 정리해야 할 초콜릿에 대한 현재 NUnit 패키지에 대한 리뷰입니다. 각각에 대해 최선의 조치라고 생각되는 내용을 추가했습니다.

다음은 현재 charliepoole 계정에 있습니다. nunit-org 계정으로 이전하려면:

• NUnit 3 - Visual Studio 프로젝트 로더 확장 3.7.0
• NUnit 3 - NUnit 프로젝트 로더 확장 3.6.0
• NUnit 3 - NUnit V2 프레임워크 드라이버 확장 3.7.0
• NUnit 3 - NUnit V2 결과 작성기 확장 3.6.0
  (지금은 v2 확장이 조직에 남아 있다고 가정하고 나중에 가능한 모든 이동을 처리합니다!)

다음은 charliepoole 및 rprouse에 있으며 nunit-org로 전송되어야 합니다.

• NUnit 3 콘솔 러너 3.8.0

다음은 현재 dtgm에서 유지 관리하는 레거시 패키지입니다. 상위 2개는 또한 charliepoole이 유지하고 있고, 세 번째는 그렇지 않습니다. 세 가지 모두 NUnit 3 Console Runner 3.8.0을 위해 더 이상 사용되지 않아야 합니다.

• NUnit(설치) 3.4.0
• NUnit 3.4.0
• NUnit(휴대용) 3.4.0

다음 NUnit 관련 도구는 NikolayP의 charliepoole에 속하며 그대로 유지되어야 합니다.

• NUnit 3 GUI 러너 0.6.0
• NUnit 3 - 팀 시티 이벤트 리스너 확장 1.0.4
• NUnit 프로젝트 에디터 1.0

다음 패키지는 지금까지 우리의 모든 토론 외부에 있는 사용자가 온라인에 올렸습니다. 우리는 적절한 시기에 NUnit-조직 패키지를 위해 사용 중단과 관련하여 사용자와 소통하고자 할 수 있습니다. 그러나 그것은 별개의 문제입니다!

• NUnit 콘솔(휴대용) 3.6.1

마지막은 서프라이즈!

TeamCity 확장에 대한 약간의 정보: 업데이트를 수행할 수 있도록 패키지 작성자로 Nikolay를 추가했지만 내 이름은 그대로 두었습니다. 그렇게 함으로써 저작권 소유자를 저자 중 하나로 유지하여 우리 패키지를 초콜릿으로 특별하게 취급할 수 있게 되었습니다. 나는 이전에 Nikolay가 대부분의 작업을 수년간 해왔기 때문에 저작권 소유자로 추가하고 싶었지만 그의 회사가 반대했습니다.

WRT가 패키지에서 나 또는 Rob을 제거하는 경우 NUnit 조직 ID를 사용하여 이를 수행하기 전에 WRT 패키지 검토를 받은 특별한 처리를 계속 제공할 수 있는지 확인해야 합니다. 키에는 패키지 작성자와 소프트웨어 소유자라는 공통된 이름이 하나 이상 있는 것 같았습니다. 그러나 내가 그것을 설정한 지 몇 년이 지났고 chocolatey.org는 그 이후로 관행을 변경했을 수 있습니다.

@ChrisMaddock 목록을

@gep13 팀 계정을 만들었습니다. nunit.org의 사용자 이름과 이메일은 [email protected]입니다. 마지막 4개를 제외하고 나열된 @ChrisMaddock 패키지에 유지 관리자로 추가할 수 있습니까? 마지막 작가님과 따로 연락해 보도록 하겠습니다.

또한 위의 @CharliePoole 주석의 마지막

WRT가 패키지에서 나 또는 Rob을 제거하는 경우 NUnit 조직 ID를 사용하여 이를 수행하기 전에 WRT 패키지 검토를 받은 특별한 처리를 계속 제공할 수 있는지 확인해야 합니다. 키에는 패키지 작성자와 소프트웨어 소유자라는 공통된 이름이 하나 이상 있는 것 같았습니다. 그러나 내가 그것을 설정한 지 몇 년이 지났고 chocolatey.org는 그 이후로 관행을 변경했을 수 있습니다.

@rprouse @CharliePoole @ChrisMaddock 요청하신 각 패키지에 새로운 NUnit Chocolatey 사용자를 추가했습니다. 여기에서 볼 수 있습니다.

https://chocolatey.org/profiles/nunit.org

이 계정과 연결된 이메일 주소를 gravatar 계정에 추가하고 NUnit 로고를 연결해 달라고 요청할 수 있습니까? 그렇게 하면 chocolatey.org에 "공식적으로" 더 많이 표시됩니다.

_특수 취급_에 관하여...

이러한 각 패키지를 신뢰할 수 있는 패키지라고 합니다 . 이는 각각의 새 패키지 버전이 여전히 자동화된 유효성 검사 및 확인 검사의 대상임을 의미합니다. 이 단계에서 새 패키지 버전이 실패하면 "관리자가 수정 조치를 취하기를 기다리는 중" 상태로 다시 전송됩니다. 신뢰할 수 있는 패키지이기 때문에 사람이 패키지를 승인할 때까지 기다릴 필요가 없습니다. 즉, 중재 프로세스를 훨씬 빨리 통과할 수 있습니다.

자, 간단히 말해서... 이 새 유지 관리자를 패키지에 추가해도 여기에서 변경된 사항은 없습니다. 이러한 각 패키지는 여전히 신뢰할 수 있습니다.

@rprouse @CharliePoole @ChrisMaddock 방금 다음 패키지를 살펴 보았습니다 .

• https://chocolatey.org/packages/nunit
• https://chocolatey.org/packages/nunit.install
• https://chocolatey.org/packages/nunit.portable

지원 중단 프로세스를 통해:

https://chocolatey.org/docs/how-to-deprecate-a-chocolatey-package

또한 해당 패키지에 있던 모든 유지 관리자를 제거했습니다.

나머지 질문이 있거나 제가 처리해야 할 다른 사항이 있으면 알려주세요.

@gep13 더 이상 사용되지 않는 packaegs가 나에게 맞는 것 같습니다. 감사 해요!

훌륭합니다, 감사합니다 @gep13! 내일 그라바타를 보려고 합니다. 😊

그래서!

1. gravatar를 추가하고 nunit.org의 choco 프로필을 채웠습니다(https://chocolatey.org/profiles/nunit.org).
2. @gep13 은 우리의 모든 지원 중단 및 신규 유지
3. 조직이 아닌 NUnit 패키지(https://github.com/Roemer/Chocolatey-Packages/issues/7) 중 하나를 더 이상 사용하지 않는 문제를 만들었습니다. @Roemer 가 패키지를 그대로 두는 것을 선호할지 여부는

그것으로, 나는이 문제를 닫을 수 있다고 생각합니다! 😄 만세!

WRT가 패키지에서 나 또는 Rob을 제거하는 경우 NUnit 조직 ID를 사용하여 이를 수행하기 전에 WRT 패키지 검토를 받은 특별한 처리를 계속 제공할 수 있는지 확인해야 합니다.

@CharliePoole @rprouse - @gep13 에서 패키지 검토 프로세스가 그대로

예를 들어 다음은 우리가 Cake에서 하는 일입니다.

https://chocolatey.org/packages/cake.portable

cake-build 계정은 모든 사람이 액세스할 수 있는 조직 계정이며, 실제로 새 패키지를 chocolatey.org에 푸시하는 계정입니다. 그러나 모든 유지 관리자의 개인 계정도 다음과 같이 패키지에 추가합니다. 잘. 이를 통해 사람들은 자신이 누구인지 알 수 있지만, 또한 사람들이 chocolatey.org의 패키지와 관련된 "인터넷 포인트", 즉 다운로드 수 등을 얻을 수 있습니다.

@gep13 감사합니다. 조직적으로 어떻게 하고 싶은지 생각해 볼 문제인 것 같아요. 전통적으로 모든 것이 Charlie Poole의 이름으로 출시되었습니다. 우리는 이제 그런 곳에서 좀 더 분산된 조직으로 이동했습니다.

항상 모든 기회(예: 출시 발표)에 기여자에 대해 외치는 Cake의 팬이었습니다. 우리는 그 이상을해야합니다! 😄