branch 전략 논의

[mhyeon-lee]

• 다음 patch 버전을 올리기 위한 branch 와 과 break change 가 있어 마이너버전을 올리기 위한 branch 가 별도로 관리될 필요가 있을거 같습니다.
• branch 전략을 어떻게 가져가면 좋을지 정할 필요가 있습니다.

[mhyeon-lee]

spring 쪽을 보면 main branch 는 계속 merge 가 되고, 별도로 호환 관리해야될 패치 버전 브랜치는 따로 따서 관리하는거 같습니다.
저희쪽에 상황을 적용시키면

1. 0.3.x 브랜치를 만든다.
2. PR 들은 main 에 merge 한다.
3. 0.3.x 패치 버전에 반영해야 되는 커밋은 main 에서 0.3.x 브랜치로 merge 한다.
4. 0.3.x 다음 패치 버전 릴리즈는 0.3.x 브랜치로 릴리즈한다.
5. 다음 마이너 버전 릴리즈시에는 main 에서 0.4.0 을 릴리즈하고, 0.4.x 브랜치를 만든다.
6. 이후 커밋 중 0.4.x 에 패치할 커밋은 0.4.x 에 반영한다.

---

위의 정책에 따라서 현재 main 기준으로 0.3.x 브랜치를 만들겠습니다.

[mhyeon-lee]

@seongahjo 0.3.x 브랜치 만들었습니다.
commit 중에 0.3 패치에 들어갈 커밋은 0.3.x 브랜치에 추가로 머지 또는 체리픽 해주면 되겠습니다.

0.4.x 에 반영할 PR 은 main 에 merge 하면 될거 같습니다.

[mhyeon-lee]

0.3.x 에 merge 됐을 때 돌아갈 PR Builder 셋팅도 부탁드릴께요

[mhyeon-lee]

@seongahjo 혹시나 해서 말씀드리는데 쉬는날이니까 지금 안하셔도 됩니다.
오픈소스 활동과 업무의 경계가 애매하긴한데 이것도 한번 이야기 해봐야겠네요

[seongahjo]

넵 좋은 것 같습니다. 관리를 위한 브랜치가 있는 게 유연하게 대응할 수 있을 것 같군요.

혹시나 해서 말씀드리는데 쉬는날이니까 지금 안하셔도 됩니다.

ㅋㅋㅋㅋ 쉬다가 심심할 때 하고 있습니다.

A.B.x 와 같은 형식으로 고정되면 branch protection rule을 적용할 수 있을 것 같습니다.
깃헙 액션에서도 가능할지 확인해봐야겠군요

[seongahjo]

릴리즈 노트를 작성할 때 pr 버전을 참조하면 될 것 같군요.

squash merge를 강제해놓길 잘한 것 같습니다.
커밋 이름에 PR 번호가 없는 게 좀 불편하긴 하네요.

[mhyeon-lee]

@seongahjo
커밋과 이슈를 어떻게 연결할지도 논의해봐야겠네요

@benelog 님의 많은 경험상 깃헙이나 jira 등 플랫폼에 의존한 링크를 커밋 메시지에 남겨놓으면 이후 마이그레이션 등의 작업시 굉장히 어려움 등이 있어서 선호하지는 않는데요
어떻게 관리하면 좋을지 혹시 아이디어가 있을까요?

[mhyeon-lee]

@seongahjo 님 document 문서는 마이너 버전 단위로 컨텐츠 폴더 자체를 복사하면 어떨까요?
현재 0.3.x doc 폴더가 있고 0.3.1, 0.3.2 는 해당 폴더에 반영하다가
0.4.0 으로 갈때 폴더를 0.4.x 폴더로 복사하고 0.4.1, 0.4.2 등을 업데이트하고

하나로 퍼블리시 되서 마이너 버전 단위롤 메뉴에 링크거는 방식으로 가능할까요?

[seongahjo]

@mhyeon-lee
넵 저도 그런 방법을 생각했습니다. 유사하게 적용한 사례들이 많더라구요.
퍼블리시가 가능할지는 모르겠습니다.
이런저런 실험을 해봐야 알 것 같습니다.

[benelog]

@mhyeon-lee
주로 GitHub의 자동링크가 깨어지는걸 많이 봐서, 자동링크를 디폴트 정책( #{issueNo}) 으로는 안 썼으면 하는 의견이 가장 큽니다.
스프링에서는 본문에 gh-{issueNo} 스타일로 쓰고 있네요.
(전에는 full URL을 적었던것 같은데 바뀌었나봅니다.)

spring-projects/spring-framework@93f8706

이슈 트래커별 prefix를 정하고 autolink 설정을 활용하면 이슈 트래커를 갈아타더라도 이전 링크가 깨어지지 않는다는 장점이 있습니다.
그런데 커스텀 autolink기능이 아래 가이드와는 달리 저희 저장소에는 안 보이네요; 추가로 돈을 지불해야나오는건지, 아니면 GitHub가 업그레이드되면서 위치가 바뀌었는지는 확인이 필요합니다.

• https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/configuring-autolinks-to-reference-external-resources
• https://github.blog/2019-10-14-introducing-autolink-references/

커스텀 autolink가 잘 된다면, 이슈 링크를 commit title에도 넣을것인지, 본문에 넣을것인지만 결정하면 될듯합니다.
(두 방식의 장단점의 저울이 한쪽으로 크게 기울지는 않는 느낌이라, 어느쪽이든 전 크게 상관없긴하니다.)

---

그리고 버전별 branch를 따로 유지하는 단위는 하위호환성을 어떤 버전까지 가져갈지와 연관이 있어보입니다.
semver에 충실한다면 MAJOR.MINOR.PATCH 에서 MINOR까지는 하위호환성을 유지하게 됩니다.
이 규칙에 따른다면 0.4,x 가 나온 이후에도 0.3.x 에 백포트 패치의 필요성은 줄어듭니다.
0.3.x -> 0.4.x 는 기능추가만 있기 때문에 ​0.3.x 사용자에게는 0.4.x 바로 업그레이드하라고 하면 됩니다.
이 정책이라면 버전별 branch는 0.x, 1.x 단위로 유지될수 있지 않을까합니다.

(스프링은 MINOR가 올라갈때 breaking change가 있어서 위와 같이 branch를 나누지 않았나 싶습니다.)

그리고 최신 버전에 대한 branch가 따로 나오는 시점은 main 브랜치에 Breaking change가 들어가는 시점이 되어도 될것 같습니다.
그전까지는 최신버전에 대한 branch가 따로 있어도 main -> 최신버전 branch 반영은 fast-forward merge가 되고, 해당 브랜치가 태그 이상의 존재 가치는 크게 없어보입니다.

그래서 우선 결정해야할 사안은 '현재버전이 0.3.0인데, 다음의 기능추가 버전으로 0.4.0을 내고도 0.3.x에 대한 백포트 패치를 계속할것인가?' 의 여부입니다.
백포트 패치의 비용도 있으므로 하위호환성을 유지하는 버전 내에서는 상위 MINOR 버전으로 업그레이드를 권장하고, 백포트는 MAJOR 버전업 때의 breaking change 이후에 고려하는 방안이 fixture-monkey의 현재 사용자층이나 프로젝트 규모에 더 적합하지 않나 저는 생각합니다.

[mhyeon-lee]

@jwChung 님이 알려주셨었는데 semver 에서 MAJOR 가 0 일때는 MINOR 에서 breaking 해도 된다고 하네요

https://semver.org/#spec-item-4
https://semver.org/#spec-item-8 (X.y.z | X > 0)

그래서 우선은 breaking 이 있을 때 MINOR 를 올리려고 합니다.

현재 생각하는 백포트는 이전 MINOR 버전에 대한 백포트 패치 요구사항이 있을때 (내부적이든 외부 요청이든) 작업 범위나 리스크를 보고 백포트 패치를 할까 합니다.

[benelog]

@mhyeon-lee
말씀해주신바로는 0.3.x 대의 백포트 패치 여부는 아직 불확실하다고 이해했습니다.
그렇다면 0.3.x의 브랜치를 따로 따서 관리하고 별도의 PR builder까지 설정하는 작업은 백포트 패치를 해야겠다고 의사 결정되는 시점에 하는 것은 어떨까요?
필요성이 명확하기 전까지는 가급적 단순한 브랜치와 설정으로 작업 비용을 줄이는 것이 좋지 않을까 생각되어서 입니다.
백포트 패치를 안 할때의 태깅 대비 버전별 branch의 장점을 생각해봤는데, 당장은 떠오르지는 않았습니다.

그리고 이 라이버리리에 관심을 가지는 분들을 위해서 1.0.0버전에 대한 로드맵도 필요해보입니다.
0.x 대 버전에서는 API가 많이 바뀔수 있다고 판단하여 fixture-monkey를 실무에서 사용하기를 주저하는 분들이 많을 법합니다.
semver에서 0.x 대에서는 MINOR의 breaking change를 허용한것도, 0점대 버전에서는 일반적으로 API가 불안정하다는 상황을 감안한 것일듯합니다. 이를 감안하고도 0.x를 쓸 사람은 breaking change에 대한 감내성도 높아서 백포트 패치에 대한 기대도 낮을것으로는 기대할수 있습니다.

현재의 API가 꽤 많은 토론을 거쳐서 완성된 것이고, 사내 실무 프로젝트에서도 쓰이고 있으니 지금 버전을 1.0버전으로 해도 괜찮지 않을까 싶은데요, 이런 성아님과 명현님이 생각하시는 앞으로의 계획에 따라서 달라질것 같습니다.
당장 사내 프로젝트들 때문에 현재의 버전도 백포트를 해야할 가능성을 배재할수 없는듯한데, 이런 상황도 지금 버전이 실제적으로 1.0 이상이라는 신호같기도합니다.

[mhyeon-lee]

1.0.0 으로 오픈하려다가 0.3.0 으로 진행한 것은 오픈한 후에 한번 정비가 필요한 부분도 있고, 사용자 의견을 받아 보고 Breaking 이 필요한 제안이 있을지 몰라서 우선 0.3.0 으로 오픈하기로 했었습니다.

0.x.x 를 오래가지고 갈건 아니고 아래 정도를 정리한 후에 1.0.0 으로 올릴까 생각하고 있습니다.

1. fixture-monkey-api 모듈로 spi interface 이동
   • 외부 모듈에 확장을 제공할 interface 들을 fixture-monkey-api 모듈에 선언하고, fixture-monkey 의 기존 interface 는 @Deprecated 마킹합니다. 마킹된 @Deprecated 는 1.0.0 버전업시 제거됩니다.
2. jqwik 버전업
   • fixture-monkey 에서 사용하는 jqwik 은 1.3.9 인데, 현재는 1.6.0-SNAPSHOT 까지 나와 있습니다.
   • 버전업을 따라가지 않은 이유는 1.4.0 부터 edge case 기능 추가에 따른 내부 구조 변화가 있었고, performance 이슈가 있고 jqwik engine 을 사용하지 않았을 때(junit-jupiter-engine 을 사용할 때) 메모리 릭 이슈가 있습니다.
   • jqwik engine 을 사용하지 않았을 때 performance 이슈는 더 크게 발생합니다.
   • 우선 jqwik engine 을 사용하지 않았을 때 메모리 릭 이슈는 제가 PR 2개 컨트리뷰션해서 해결했습니다.
     • Change Memoize cache to LruCache jqwik-team/jqwik#234
     • Change SampleStreamFacade static generators to LruCache jqwik-team/jqwik#233
   • performance 이슈는 계속 보완하고 있는거 같습니다.
     • Performance degradation with 1.4.0 jqwik-team/jqwik#166
     • Performance Degradation with 1.5.3 jqwik-team/jqwik#206
     • Performance Degradation with 1.5.4 jqwik-team/jqwik#214
   • 위의 보완 내용들이 반영됐음에도 fixture-monkey 에 있는 테스트 케이스로는 1.3.9 와 1.6.0-SNAPSHOT 의 시간 차이가 발생합니다.
   • 실행 테스트: 테스트 케이스 200개 가량 * 1000 (테스트 단위 반복 횟수) = 25만회 실행
   • 1.3.9 : 6m 10s ~ 6m 30s, 1.6.0-SNAPSHOT : 9m 10s ~ 9m 30s
   • 1.5 배 정도 느린거 같습니다. 1.3.9 와 비교해서 Arbitrary 내부적으로 객체 생성을 많이 해서 느려진거 같은데 jqwik 이나 fixture-monkey 어느쪽에서든 더 개선할 수 있는 부분이 있을지 살펴봐야 될거 같습니다.
   • jqwik 버전업을 하면서 추가된 기능들이 도움이 되는 기능이라 가능하면 퍼포먼스 이슈를 해결하고 버전업을 하면 좋을텐데요. 포기하고 jqiwk 1.3.9 로 fixture-monkey 1.0.0 을 릴리즈해도 관계는 없다고 생각합니다.
3. 내부 구조 조정
   • 개인적으로 향후 확장이나 현재의 제약사항을 보완하기 위해 구조를 조금 손보고 싶은 부분이 있는데요. @seongahjo 님이 redesign 할 때 그 부분까지 변경하면 고려 범위가 너무 커져서 진행하지 않았었습니다.
   • 가능한 breaking 이 발생하지 않게 하려고 하지만 이 얼마나 breaking 이 발생할지 좀 검토해봐야 되서 보류하고 있습니다.
   • 검토해본 후에 breaking 발생이 얼마나 필요한지 판단됨에 따라 1.0.0 에 반영 여부를 판단할 생각입니다.