release policy and quicklisp

[Lucien Pullen]

Also sprach Luís Oliveira on 2016-02-19:
> On Mon, Feb 15, 2016 at 11:53 PM, Attila Lendvai <attila at 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:
>
> 1. 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.)