| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
The instructions are purposely a bit coy about what files are updated,
so we don't have to update immediately when something else is plugged
into the make recipe.
|
| |
|
|
|
|
|
| |
The additional "safety feature" documented here is motivated by the
fact that I use gpg-agent and I don't always get the GPG prompt that
Carl was relying on as an abort point. The new version also allows
more to be done in "dry run" mode.
|
| |
|
|
| |
This is definitely reaching the point where it should be automated.
|
| |
|
|
|
|
|
|
| |
We really did bump SONAME, and we probably will again, but not just
for a simple symbol addition.
Debian versions generally need to be removed from symbols file; this
wasn't a problem before because there was no Debian versions
|
| | |
|
| |
|
|
| |
Which is ready to go now.
|
| |
|
|
|
| |
As reminded in the RELEASING instructions, the correct version is 0.4,
not 0.4.0, so update this in the NEWS file as well.
|
| |
|
|
| |
Again, just taking the one-line entries from the NEWS entry for 0.3.
|
| |
|
|
| |
Finally, a single button to push to do all the uploading.
|
| |
|
|
|
|
|
| |
Eventually I'd like to automate this so that one or the other of these
files is canonical and the other is generated from it. Until then, add
this check to the release process to avoid a skewed release being
shipped.
|
| |
|
|
|
|
| |
It is annoying to have an extra step here, but it does at least mean
that we are back to just "make release" rather than "make VERSION=X.Y
release".
|
| |
|
|
|
| |
I'd like to have this be fully automated in the future, but for now,
it's an extra step.
|
| |
|
|
|
|
|
| |
We actually want this version to be incremented by the commits that
extend the interface. So the release process really is not to just
verify two things (NEWS and libnotmuch version), then run "make
VERSION=x.y release", and send the mail. Quite nice.
|
| |
|
|
|
| |
Where by clean, we check that no files are known to git to be
modified.
|
| |
|
|
|
|
|
|
|
|
|
| |
The entire "make sure the code you want is in place" thing is part of
a larger release process that we don't document here at all. Instead,
we just focus here on the mechanics of pushing things out once the
larger process has determined the code is ready.
And the fewer steps there are, the better, (for making the
release-process as painless as possible and for avoiding any
mistakes).
|
| |
|
|
|
|
|
| |
We've now changed to using "git describe" to automatically report a
version number that changes with every git commit. So we no longer
need to manually update anything in the Makefile during the release
process.
|
| |
|
|
|
| |
This drops one manual step from our release process, (helping
to ensure we don't forget anything during the release).
|
| |
|
|
|
| |
We pass this in on the "make release" command-line rather than editing
the Makefile.
|
| |
|
|
|
| |
At the end of "make release" or at any point later with
"make release-message".
|
| |
|
|
| |
Otherwise I'm sure I'll always forget to push it.
|
| |
|
|
|
| |
So far just doing checks that the version is sane and that no release
of the same version already exists.
|
|
|
These steps might be changing a bit as we work on making the initial
0.1 release.
|
David Bremner
Jameson Graef Rollins
Carl Worth