no consistent versioning strategy

palindrom615 commented 4 years ago

recently I am maintaining nimf-git aur package.

Inconsistency of versioning between libnimf, nimf pkgconfig and git tag makes it hard to distribute over package managers.

Also, it seems no specific versioning strategy on git tag version.

ex. why does git tag 1.1 attached w/o any api changes? why does git tag nimf-1.2 has prefix?

kor: 최근 nimf-git aur 패키지 메인테넌스를 하고 있습니다.

libnimf, nimf pkgconfig, git tag간 버저닝이 일관성이 없고, 특히 git tag 버전에 일관된 규칙이 없어서 패키지 배포에 어려움을 겪고 있습니다.

예를 들어서 API 변화가 없는데 버전 1.0에서 1.1로 왜 올라갔는지, nimf-1.2 버전은 왜 접두사가 붙었는지 명확한 규칙이 없는 것 같습니다.

chaeya commented 4 years ago

@palindrom615 소중한 의견 감사합니다. 패키지 배포를 위해 어떤 버저닝 규칙과 태깅 규칙이 필요한지 알려주시면 해당 규칙을 반영하도록 하겠습니다.

Thank you for your valuable comments. Please let us know which versioning and tagging rules you need for package distribution and we will reflect those rules.

palindrom615 commented 4 years ago

Obviously entire versioning strategy depends on maintainer' taste, but if you are not used to opensource software, here are prior things to do IMO:

the very first thing! tagging v1.2.0:

git tag -a 1.2.0 4c96391
git tag -a 1.2 4c96391

Using git tag as a package versioning is not rare. archlinux pkgbuild file recommends vcs packages to get a version number from git tags. The tag nimf-1.2 breaks whole those tools.

integrate your release cycle with version

Using build date has many downsides as you guess. Replace old versioning with your one. Keeping two version numbers is never a good idea and might cause confusion someday. Imagine that another developer wants to use libnimf. There might be at least two confusion: when they installing and clarifying dependencies. no more hard-coded 1.0.0 version!

if you don't know how to version, semantic versioning is a good start! see semver documents, developer-friendly versioning.

Maintaining open-source is not an easy task and requires more than just developing a product. It seems that you are not very familiar with open-source. Good luck and feel free to ask anything!

chaeya commented 4 years ago

어떻게 버전을 관리할지 좋은 정보 공유해주셔서 감사합니다. 제안하신 내용처럼 오픈소스로 많은 사람들이 사용할 수 있도록 버전을 관리하는것이 좋겠네요. 여러가지 프로젝트가 산재되어 있어서 잘 관리하지 못하는 것이 사실입니다. 그래서 생각했는데 단순하게 버전과 태그를 수정하는 것이 아니라 @palindrom615 님에게 이 프로젝트 브랜치에 작성할 수 있는 권한을 부여하고 프로젝트를 함께 관리해보시는건 어떨까요?

palindrom615 commented 4 years ago

@chaeya 네, 콜라보레이터로 활동하면서 메인테넌스에 참여하면 정말 좋을 것 같습니다.

chaeya commented 4 years ago

@palindrom615 참여해주셔서 감사합니다. maintainer 권한을 부여했으니 nimf 프로젝트를 모든 사람이 오픈소스로 사용하기 위해 꼭 필요한 문서화와 릴리즈관리 부문에서 함께 참여해주시면 좋겠네요.

ghost commented 4 years ago

안녕하세요. 저는 nimf 원저자입니다.

https://aur.archlinux.org/packages/nimf-git/ 에 문제가 좀 있어서 연락드립니다. 이메일로 문의 드렸지만, 아무런 답장도 없고 사과도 없고 PKGBUILD 파일에 대한 조치도 없어서 부득이하게 여기에 연락드립니다. 명예를 훼손할 의도는 전혀 없습니다.

nimf-git 의 PKGBUILD 는 2015년인가 2016년인가 애초 저의 도움을 받아서 어떤 분이 만든 겁니다. 당시에도 제 이름은 쏙 빠져있었죠. 아치쪽에 이슈 올라오면 제가 해결하는 등 큰 역할을 했는데 말이죠. 당시에는 사실 그게 문제라고 생각하지도 않았습니다. 제가 PKGBUILD 왜 손을 댔냐면, 아치 문의가 자꾸 오기 때문에 nimf-git 를 직접 운영하면 오히려 시간 소비가 줄어들거라는 판단 때문이었습니다. nimf 저장소에 PKGBUILD 라는 파일을 새로 작성하였고, nimf 저장소를 통째로 올리면 자동화가 가능하기 때문에, 자동화를 위해 git push -f 테스트를 했습니다. 자동화를 하려던 이유는, 릴리즈하는 날에 잠을 못자기 때문이, 어떻게든 소요시간, 검토시간을 조금이라도 줄이기 위함이었습니다. 그러나 git push -f 가 되지 않아 nimf 저장소에 새로 작성한 PKGBUILD 를 nimf-git 에 복사하는 형태로 반자동화를 하였죠. 그래서 contributor 가 삭제되었습니다.

nimf 저장소에 PKGBUILD 는 그쪽 분들이 작업하신 걸 제가 가로챈 게 아닙니다. 그래서 nimf 저장소의 PKGBUILD 에 아치 nimf-git 에 있는 contributor 를 넣지 않는게 맞는 겁니다. 아치쪽 nimf-git 에 contributor 를 넣으려면 수작업으로 수정하고 그래야 하는데, 개발 외적인 일이 자꾸 늘어나는게 싫었습니다. 제가 nimf 를 개발해서 밥먹고 사는 사람이 아니라 본업이 따로 있는 사람입니다. 잠못자서 본업에 영향 가는게 싫었습니다. 그래서 nimf-git 에 contributor 를 넣지 않았고, 그걸 기입하기 시작하면, nimf 저장소 PKGBUILD 도 변경해야 하는데 그러기 싫었습니다. 이슈 올린 사람 이름 달기 시작하면 contributor 로 도배될 겁니다. 그쪽 분들 자꾸 문제 삼아서 2018년에 도루 원상복구 해놓았습니다.

정작 저를 욕하시는 분께서는 nimf-git 를 삭제시켰죠. 그런 일이 있었습니다. contributor 삭제했다고 저를 욕하시는 분들이 왜 2015년인가 2016년인가부터 제 이름은 쏙 빼놓으셨습니까? 최근에 nimf-git 를 복구하신거 같은데... 제 이름도 넣으시던가.. 아니면 contributor 를 모두 삭제하시고, 메인테이너 이름만 넣던가 그러세요. 메인테이너 이름 연락처를 왜 넣는 거냐면, 이름을 알리기 위해서가 아니라, 뭔가가 안 되면 연락할 수단이 필요하기 때문에 넣는 겁니다.(메인테이너 이름에 제 이름을 넣으라는게 아닙니다.)

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=nimf-git&id=92e1aac3d6bd17bcf594560b92fc67e98cfb0565

libhwp 사건도 그렇고.

nimf 프로젝트가 영원히 중단되었다고 아치 위키에 공표를 하지를 않나..

커밋 히스토리를 모두 제거하지 않나.

하모니카에서는 소스코드 변경이 없는 상태에서 저자와 협의 없이 LGPL 라이선스를 GPL 로 일방적으로 변경해서 배포하질 않나.

버전이 YYYY.MM.DD 이면 이런 식으로 계속 가야 맞는거지... 1.1, 1.2 이렇게 가면 다운 그레이드 잖아요. 이전 버전 정책 따르기 싫으면 이름을 변경해서 배포를 하던가, 버전 정책을 변경한다고 공지를 올리던가 그래야지...

README 파일을 변경하여 다국어 입력 프레임워크를 한글 입력기라고 축소하여 소개를 하죠.

오픈소스 및 소프트웨어에 개발에 대한 기본 상식조차 없는 사람들 같은데.. 미안한 얘기지만 기본적인 건 좀 지키고 삽시다.

chaeya commented 4 years ago

@cogniti2 안녕하세요. 하모니카 개발팀의 Kevin 입니다. 아치쪽은 제가 어떻게 운영되는지 알 수 없어서 우선 제가 답변드릴 수 있는 내용만 답변드리겠습니다.

라이선스 변경 부분은 하모니카 팀에서 이 프로젝트를 운영하려던 초기에 호동님이 라이선스 변경에 대한 의견을 주셔서 원래의 LGPL로 배포하도록 바뀌었고 그렇게 배포되고 있습니다. 그리고 프로젝트 릴리즈 버전 정책은 현재 프로젝트를 관리하기 용이한 상태로 간소화 했는데, 얼마전 이 이슈에서 버저닝을 일관되게 유지하는게 좋다는 의견을 받아들이고, @palindrom615 님이 함께 프로젝트 관리에 기여해 주시기로 하였습니다.
README 파일의 내용을 한국어 입력으로 표시한 이유는 다국어 환경에 대한 테스트가 모두 되었다면 다른 언어 사용자들이 사용할 수 있는 문서와 함께 그렇게 배포하고 싶지만, 현재 저희 개발팀에서 다국어에 대한 환경 테스트를 모두 하지 못하는 상태이기 때문에 확인된 내용을 위주로 재작성했기 때문입니다.

오픈소스 및 소프트웨어 개발 경험이 풍부한 분들이 함께 해주시면 프로젝트 사용자들에게는 좋은 일이니 언제든 참여하셔서 함께 좋은 소프트웨어를 배포할 수 있으면 좋겠네요. 그럼 즐거운 저녁 되시기 바랍니다.

ghost commented 4 years ago

빠른 조치에 감사드립니다. 저는 nimf 프로젝트를 진행/참여/기여하시는 분들 및 사용자 분들께 악감정이 없고, 방해할 의도가 없음을 분명히 말씀드립니다. 또한 nimf 프로젝트에 전혀 간섭하지 않고 있으며 앞으로도 간섭하지 않을 것임을 약속드립니다. 다만 제가 우려하는 것은 악성루머가 또다시 유포되는 건 아닌가.. 그런 점이 불안하기는 합니다만, 자유/오픈소스 프로젝트를 하지 않고 있으며 앞으로도 계속 자유/오픈소스 프로젝트를 하지 않음을 약속드립니다.

본 github 계정을 그대로 두면 신고당하여 계정 삭제되고 블럭 먹을 것으로 예상되기 때문에 본인 스스로 삭제하겠습니다. 오해 없으시기 바랍니다. 감사합니다.

hamonikr / nimf

no consistent versioning strategy #17