의미 초월 버전 제어

며칠 전에 소프트웨어 버전 제어와 관리 의존 관계를 어떻게 개선할 것인가에 대한 생각이 떠올랐다.나는 그것이 도대체 어떻게 일을 하는지 아직 확실히 알지 못했지만, 나는 내가 먼저 나눠야 한다고 생각한다.

누가 의미 버전 제어를 따릅니까?
Semantic Versioning는 좋은 생각이다. 많은 항목이 그것을 따르고 싶지만 모든 항목이 100% 할 수 있는 것은 아니다.문제는 앞으로 호환되지 않는 변경 사항이 도입될 때마다 메인 버전이 늘어나는 것이다.사람들은 현재 버전이 1.3인 상황에서 MyLib 2.0을 발표하고 싶지 않다. 새 버전은 버그 하나만 복구되어 어떤 경우에는 이전 버전의 호환성을 파괴할 수 있다.다른 한편, 프로그램이나 라이브러리가 MyLib에 의존하는 사람으로서, 나는 모든 프로그램에서 안전하게 그것을 업데이트할 수 있기를 바란다.어떤 변경이 나의 코드를 파괴할 것이라고 걱정할 필요가 없다.
일부 항목이 정말 메인 버전을 추가했다. 설령 가장 가벼운 호환성이 없다 하더라도, 나는 v5 업그레이드 라이브러리에서 3개월 후에 이 점을 보는 것이 매우 무섭다는 것을 발견했다.0에서 v8까지.0, 지금 v12로 업데이트해야 합니다.0, 작지만 파괴적인 변경이 있기 때문이다.일반적인 상황에서, 나는 주요 버전이 중대한 변경을 도입하기를 희망한다. 비록 나는 이것이 샘프가 말한 것이 아니라는 것을 알고 있지만, 나는 생각을 멈출 수 없다. v3에서 v4로 이전하는 것이 반드시 안전한 복구만이 아니라는 것을.
나는 나의 기대가 전혀 근거가 없는 것이 아니라고 믿는다. 내가 사용한 대부분의 대형 라이브러리에 있어서 다음 주요 버전은 관리자가 정성껏 기획한 것이다. 변경을 타파하고 새로운 기능을 도입하는 것을 고려하고, 때로는 대량으로 다시 쓰기도 한다.그들은 X.Y.Z 버전 제어를 사용해 왔으며 버전을 주요 버전, 보조 버전, 마이크로 버전이라고 부른다.그러나 이들은 의미 버전 제어를 엄격히 따르지 않았다.

SemVer->breaking.json?
그래서 나는 우리가 무엇을 할 수 있을지 계속 생각했다. 만약 우리가 다른 방식으로 저장소의 돌파적인 변경 사항을 표시할 수 있다면?예를 들어, 중단된 변경 사항이 있는 버전 목록을 포함하는 유사breaking.json 파일이 있습니다.

{
  "3.5.0": [
    {
      "change": "myProperty function has been removed",
      "details": "https://github.com/MyName/MyRepo/issue/4321",
      "impact": "low"
    }
  ],
  "3.0.0": [
    {
      "change": "myname function renamed to myName",
      "details": "https://github.com/MyName/MyRepo/issue/4002",
      "impact": "high"
    }
  ]
}

이렇게 하면 npm update 또는 다른 명령을 실행할 때 현재 버전과 업그레이드할 버전 사이에 어떤 돌파적인 변화가 발생했는지, 그리고 세부 사항과 가능한 조작 설명을 볼 수 있다. 그리고 나는 계속할지 낮은 버전을 선택할지 결정할 수 있다.호환되지 않는 것을 발견할 때 항상 멈추거나, 무엇을 할 것인지, 내가 사용할 수 있는 최신 버전의 목록을 출력할 수 있는 미리 정의된 설정을 사용할 수 있습니다. 나중에 호환되지 않는 변경 사항은 필요 없습니다.업데이트 라이브러리를 더욱 복잡하게 만들 수 있지만, 개발자들에게 화면의 변경 사항을 이해하게 할 수 있는 방법은 많다.

찬성 의견

이터레이션에서 소규모 변경 작업을 수행할 수 있습니다. 작성자는 2년마다 대규모 업그레이드 가이드를 삭제하는 대신 여러 이터레이션에 소규모 변경 사항을 도입할 수 있습니다

.

주요 변경 사항의 주요 버전을 보존할 수 있음

사용자가 특정 버전

의 업데이트를 손상시키지 않고 최신 버전을 찾을 수 있도록 함

이것은 좀 억지스럽다. 그것은 엄격한 의존 관계를 커버할 수 있다. 예를 들어 MyApp은 MyLib 1.5와 MyOtherLib 1.3을 사용할 수 있다.MyOtherLib을 2.0으로 업데이트하고 싶지만, MyOtherLib 버전 1에 의존하기 때문에 업데이트할 수 없습니다.x;현재, 나는 MyLib 관리자에게 의존 관계나 지점 라이브러리를 취소하도록 해야 한다.이 기능이 있으면 나는 자신의 파괴적인 변경 목록을 볼 수 있고, 만약 내가 안전하다고 생각한다면, 나는 MyOtherLib 2.0을 강제로 설치할 수 있다.

기만하다

패키지 매니저의 추가 지원이 필요합니다. NPM/Bundler/Hex 및 기타 패키지 매니저는 이러한 기능을 승인하고 유지 보수해야 합니다

의존 관계 관리는 더욱 까다로워질 것이다. 예를 들어 나는 나의 의존 관계를 갱신하고 있는데 나의 간접 의존 관계에 돌파적인 변화가 생겼다. 나는 어떻게 해야 합니까?나는 심지어 도서관도 모른다. 나는 어떻게 그것을 갱신하는 것이 안전한지 결정합니까?

관리자가 변경 로그의 일부가 되지 않는 한 변경 목록을 다른 파일에 저장하고 최신 상태로 유지해야 합니다.

거의 우리가 얻을 수 있는 최선인가요?
나의 생각은 상당히 이상적이어서 실현하기 어려울 것이다.나도 이것이 정말 이런 상황을 개선시킬 수 있을지 확실하지 않다.아마도 현재 사람들이 주로SemVer를 사용하는 방식이 우리가 얻을 수 있는 가장 좋은 방식일 것이다. 여기서 약간의 돌파적인 변화가 있는데 다른 소프트웨어에 의존하면 비용이 들까?
이러한 상황을 개선할 수 있는 확실한 방법이 있는지 모르겠지만, 업그레이드할 때 사용자에게 보여줄 수 있는 파괴적인 변경 목록을 추가하는 것은 최소한 의식을 향상시키는 한 걸음이라고 생각합니다. 이것은 소스 관리자가 같은 질문에 대답하고 반복적인 문제를 해결하는 시간을 절약할 수 있다고 생각합니다.
소프트웨어 버전 제어와 관리 의존 관계를 개선할 수 있는 다른 방법이 있다고 생각합니까?