# versioning

jongil512

API는 웹 개발시 사실상 필수적으로 들어가는 요소이고 서버와 클라이언트를 이어주는 중요한 다리 역할을 한다. 그런데 이렇게 중요한 API가 변경되는 순간 만약 클라이언트가 해당 사실을 알지 못하고 기존의 API로 요청을 보내 404 에러를 만난다면 얼마나 당황스러울까

young_pallete

sementic-release + husky + github action + commitizen + commitlint로 손쉽게 버저닝과 CHANGELOG + 릴리즈 노트 생성 여부에 맞춰 관리하기

eastperson

소프트웨어 관리를 하다보면 ‘의존성 지옥’ 문제에 빠지게 된다. 의존성이 높은 시스템에서 명세를 엄격하게하면 모든 패키지의 버전을 업그레이드 해야 배포할 수 있는 경우가 생긴다. 반대로 느슨하게 관리를 하면 버전이 엉켜서 호환이 안맞는 경우가 생길 수있다.이번 글에서는

windowed

개요 서로 다른 client간에 행동을 지정 할 수 있도록 해줌 Versioning은 request의 request URL 혹은 headers에 따라 결정됨 사용 Versioning이 활성화 되면 request.version 을 사용해 확인 가능 예시 def

ktaewon98

MAJOR.MINOR.PATCHMAJOR : API가 변경되었을 경우MINOR : 숫자가 바뀌더라도, 함수를 사용하는 데에는 문제가 없는 경우새로운 기능만 추가된 경우PATCH : 새로운 기능 추가 + bugfixnpm에서도 같은 형태로 버전을 관리함Patch rele

heumheum2

운영을 하면서 서버의 API가 수정되거나 추가는 불가피하게 일어난다. 그때마다 클라이언트의 버전을 업데이트하라고 강제성을 띄우면 유저경험이 좋지 않다. 하위호환성 체크를 위해 API도 버전 관리가 필요하다.API Versioning 전략에는 여러 방법이 있다.요청하는

rxjw95

Semantic Versioning에 대해서

primadonna

노드 패키지의 버전은 SemVer(유의적 버저닝) 방식을 따름Major(주 버전) : 하위 버전과 호환되지 않은 수정 사항이 생겼을 때 올림 Minor(부 버전) : 하위 버전과 호환된는 수정 사항이 생겼을 때 올림Patch(수 버전) : 기능에 버그를 해결했을 때 올