Release management
bentley opened this issue · 3 comments
It would be great to provide a release tarball for use in package managers.
Here is the procedure for using Github's download service to provide a tarball, assuming 46c9daf... is the commit to base the release on:
$ git tag -a v2.1.2 46c9daf96fc9f14497868ea752195773e17e2751
$ git push --tags
$ git archive -o /tmp/nvi-2.1.2.tar.gz --prefix=nvi-2.1.2/ 46c9daf96fc9f14497868ea752195773e17e2751
- go to https://github.com/lichray/nvi2/releases/new
- Type 'v2.1.2' in the "Tag version" box
- Type 'nvi-2.1.2' in the "Release title" box
- Add the tarball created by git archive
(Uploading the tarball manually rather than using Github's auto-generated tarballs might seem strange. But the auto-generated tarballs are bad for two reasons: they have ambiguous filenames ("v.2.1.2.tar.gz" instead of "nvi-2.1.2.tar.gz"), and they don't have stable checksums--sometimes Github upgrades their underlying tar, gzip, or git installs in a way that changes the resulting tarballs, and when this happens packagers have to update all checksums of all files generated by Github. Better to provide a manual copy with a stable checksum.)
The result looks like this: https://github.com/bentley/nvi2/releases
At the early stage of this project, I did made unstable changes. But now things is changed: I can guarantee Nvi2 to be "ready to release at every commit", because https://github.com/lichray/nvi2/wiki/Porting the main goal of the project is to be used in base systems, where no package management involves (Nvi2 does not support Linux), and stability is desired at any time.
OpenBSD currently only has nvi2 in ports. To ease the distfile management, I think you can just upload them to your branch.
Fair enough.