Also sprach Luís Oliveira on 2016-02-19:
On Mon, Feb 15, 2016 at 11:53 PM, Attila Lendvai attila@lendvai.name wrote:
my proposal:
set up a branch called 'quicklisp' in the CFFI repo and change ql to capture that instead of the release tgz. this is what VCS'es are designed for after all.
I kind of like the current process. I run script/release.lisp which does the following:
- Creates a version tag a pushes it. (shows up in
https://github.com/cffi/cffi/releases) 2. Creates a gpg signed tarball wherein the cffi.asd contains the correct version without cluttering the git history with version bump commits.
In one of my programs, I do a "git describe --dirty --long" (format "tag-#commits-id['-dirty']") to generate the build number string, which I then load in a defining form. `git-describe' uses the latest tag on the current branch.
This avoids cluttering commit history with version bumps, since everything is in tags.
What would be the benefits of using a branch or moveable tag instead of a tarball? (Can we gpg-sign a tag?)
A signed tag is a commit object (a lightweight tag is just a pointer), so it would be harder to adjust the tag to do version bumps. This is more of what a branch would be for; a "version 3" (for example) branch in ASDF that contains all the release code for ASDF 3, where you --no-ff merge in from master or whatnot once testing is done. Create tags as normal.
You'd point quicklisp at the branch head, instead of just the tag.
(Partly related, I've been working on loading ASDF systems directly from a git repository instead of the traditional way of loading code through the filesystem. Except for the FASL cache and C files (of which I've not touched yet), it looks promising.)