the situation: hu.dwim.sdl depends on the new cffi/c2ffi stuff, and it's needed for projectured. to make playing with projectured simple, in its readme and its build.sh we rely on ql. ql takes its snapshot of CFFI from the CFFI release tgz, so hu.dwim.sdl cannot be added to the next ql release. my goals: have a shorter "release" cycle when it comes to ql snapshots. 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. sidenote: i think in the long run it would be better to use a moving tag for this, but for now the ql infrastructure doesn't support that for git repos. unfortunately git doesn't handle well when history is overwritten with a push -f on the remote side, but tags don't have that problem (git fetch --tags readily overwrites local tags with the remote ones). a small glitch in this almost ideal release management scheme is that git overwrites tags as opposed to keeping a stack of them and thus doesn't presere their history. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “You are what you do, not what you say you’ll do.” — Carl Jung (1875–1961)
On Mon, Feb 15, 2016 at 11:53 PM, Attila Lendvai <attila@lendvai.name> wrote:
my goals:
have a shorter "release" cycle when it comes to ql snapshots.
Agreed. The current master had an important regression in cffi-grovel that was only recently fixed and that had been holding back the release for a while.
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. 3. Uploads the tarball, an updated copy of the manual, and some magic version info to common-lisp.net. What would be the benefits of using a branch or moveable tag instead of a tarball? (Can we gpg-sign a tag?) Cheers, -- Luís Oliveira http://kerno.org/~luis/
On Mon, Feb 15, 2016 at 11:53 PM, Attila Lendvai <attila@lendvai.name> wrote:
my goals:
have a shorter "release" cycle when it comes to ql snapshots.
Agreed. The current master had an important regression in cffi-grovel that was only recently fixed and that had been holding back the release for a while.
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. 3. Uploads the tarball, an updated copy of the manual, and some magic version info to common-lisp.net.
What would be the benefits of using a branch or moveable tag instead of a tarball? (Can we gpg-sign a tag?)
Yes, you can but the two things are not mutually exclusive. You can do both, e.g. set both a version tag and a "latest_release" tag. The tarball you can fetch it from github. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
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:
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.)
On Fri, Feb 19, 2016 at 6:39 PM, Lucien Pullen <drurowin@gmail.com> wrote:
(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.)
This is interesting. :-) What use cases do you have in mind? -- Luís Oliveira http://kerno.org/~luis/
participants (4)
-
Attila Lendvai -
Lucien Pullen -
Luís Oliveira -
Stelian Ionescu