버전 관리

워크플로우 실행 엔진, 워크플로우 정의, 블록의 버전 관리 방식.

블록 개발자 관점에서 특히 Workflows 생태계의 생명 주기를 이해하는 것은 중요한 주제입니다. 적용되는 규칙은 다음과 같습니다:

• Workflows는 ...의 일부입니다 inference - 패키지 자체는 구성 요소 중 하나라도 변경되고, 해당 변경 사항이 게시 준비가 되면 릴리스가 이루어집니다

• Workflows 실행 엔진은 자체 버전을 선언합니다. 계획은 다음과 같습니다:

  • Workflows의 코어는 실행 엔진의 여러 버전을 호스팅할 수 있습니다. 예를 들어 현재 안정 버전과 개발 버전입니다

  • 안정 버전은 유지 관리되며, 새 버전이 필요해지고 새 버전이 승인될 때까지 새로운 기능이 추가됩니다

  • 새 버전이 완전히 운영 가능해지면, 이전의 안정 버전은 단계적으로 사용 중단되기 시작합니다. 이때 일정 유예 기간 동안 구 버전에는 버그 수정 패치가 적용되지만(새 기능은 추가되지 않음), 그 이후에는 그대로 유지됩니다. 유예 기간 동안에는 블록 제작자들에게 새 버전의 요구 사항에 맞게 플러그인을 업그레이드하도록 요청합니다

  • 코어 라이브러리는 각 메이저 버전마다 실행 엔진 버전을 하나만 유지합니다. 이는 해당 메이저 내 기능이 호환성을 깨지 않을 것이며, 버전 1.0.0 에서 생성된 워크플로가 완전히 기능할 것이라는 약속을 의미합니다 1.4.3 의 실행 엔진

• 시간이 지나도 생태계의 안정성을 보장하기 위해:

  • 각 Workflow 정의는 호환되는 실행 엔진 버전을 선언합니다. 코어 라이브러리가 실행 엔진 버전을 하나만 유지하므로, 버전: 1.1.0 Workflow 정의에서는 실제로 실행 엔진의 버전 >=1.1.0,<2.0.0

  • 각 블록은 매니페스트에서 적절한 실행 엔진 호환성을 제공해야 합니다. 예를 들어, 블록이 다음에 도입된 실행 엔진 기능에 의존한다면 1.3.7 다음과 같이 명시해야 합니다 >=1.3.7,<2.0.0 를 엔진의 호환 버전으로

• Workflows 블록은 선택적으로 버전 관리를 할 수 있습니다(이를 권장하며 Roboflow 플러그인에도 적용합니다).

  • 블록의 유형 식별자에 대해 다음 명명 규칙을 제안합니다: {plugin_name}/{block_family_name}@v{X} 블록 식별자 네임스페이스를 잘 활용하기 위해

  • 버그 수정이 필요할 때는 블록의 특정 버전만 수정하고, 그 외의 모든 변경 사항은 새 버전을 생성해야 한다고 제안합니다

  • 블록의 각 버전은 새 모듈로 제출해야 합니다(에서 제안한 대로 여기) - 심지어 코드 중복을 감수하더라도 이 특정 사례에서는 안정성이 DRY보다 더 중요하다고 보기 때문입니다

  • 비슷한 맥락에서, 각 블록은 가능한 한 독립적이어야 한다고 제안합니다. 블록 간에 공유되는 코드는 의도치 않게 다른 블록을 수정하여 Workflows의 안정성을 해칠 수 있기 때문입니다