업스트림(소프트웨어 개발)
Upstream (software development)소프트웨어 개발에서 업스트림은 소스 코드로 배포되는 소프트웨어의 원래 작성자 또는 유지관리자를 향한 방향을 가리키며 버전(원작자가 업스트림 소스 코드를 기반으로 릴리스), 버그 또는 패치의 자격입니다.
실제 예:
- 업스트림으로 전송되는 패치는 소프트웨어의 원래 작성자 또는 유지관리자에게 제공됩니다.승인될 경우 작성자 또는 유지관리자는 즉시 또는 향후 릴리스에 패치를 소프트웨어에 포함시킵니다.패치가 거부될 경우 패치를 제출한 사람은 작성자의 소프트웨어를 배포해야 합니다.
- 업스트림 저장소 또는 소스 코드 배포 버전.소스 코드가 구체적으로 패키지화된 버전 태그 부착 릴리스, 특정 커밋 또는 마스터(최신 커밋의 경우 jargon) 중 하나입니다.커스텀 디스트리뷰션(포크 등)에서는 업스트림 패치를 모두 통합하지 않았기 때문에 버그 수정이나 개선(원작자, 업스트림과 관련된 프로젝트 완성)이 누락되어 있을 가능성이 있습니다.이러한 경우, 커스텀 분배는 그것을 사용하거나 유지 보수하는 사람들의 특정 요구와 요건에 적합하도록 조정되었을 수도 있다.이는 의존관계(벤더 패키지)에서도 자주 볼 수 있습니다.사용자는 기본버전을 한 번만 받아들이고 그대로 유지하는 경향이 있습니다.이러한 환경에서는 시간이 지남에 따라 (임의적인) 수정이나 비표준적인 용도가 축적되어 최신 업스트림 패치를 커스텀 디스트리뷰션으로 통합할 수 없게 됩니다.패치와 기능의 호환성을 확보하고, 업스트림에 패치가 붙어 있는 동안, 스스로(및 독자적인 방법으로) 해결한 버그의 중복을 회피합니다.많은 커스텀 배포 사용자는 여전히 중요한 업스트림 패치(보안 취약성 등)를 선택하여 통합합니다.
업스트림 개발에서는 다른 디스트리뷰션이 향후 릴리스를 픽업하거나 최신([1]또는 모든) 업스트림패치를 Marge할 때 이 디스트리뷰션의 이점을 얻을 수 있습니다.마찬가지로 사용자가 패치를 업스트림으로 송신하는 경우, 원래의 작성자(업스트림 유지)는 커스텀 배포로부터 발생하는 기여로부터 이익을 얻을 수 있습니다.
이 용어는 버그에도 관련되어 있습니다.버그에 대한 책임은 배포의 이식, 비업스트림 수정 또는 통합에 의한 것이 아닌 경우 업스트림에 있다고 합니다.
「 」를 참조해 주세요.
레퍼런스
- ^ "Staying Close to Upstream Projects :: Fedora Docs". Fedora Project. Retrieved 2022-01-18.
{{cite web}}: CS1 maint :url-status (링크)
