debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-22 19:08:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/RELEASING

114 lines
4.1 KiB
Text
Raw Normal View History

RELEASING: Remove a meaningless step from the release process. 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).
2010-04-16 04:55:11 +02:00
Here are the steps to follow to create a new notmuch release.
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Remove a meaningless step from the release process. 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).
2010-04-16 04:55:11 +02:00
These steps assume that a process (not described here) has already
been followed to determine the features and bug fixes to be included
in a release, and that adequate testing by the community has already
been performed. The little bit of testing performed here is a safety
check, and not a substitute for wider testing.
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Remove a meaningless step from the release process. 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).
2010-04-16 04:55:11 +02:00
OK, so the code to be released is present and committed to your git
repository. From here, there are just a few steps to release:
1) Verify that the NEWS file is up to date.
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
Read through the entry at the top of the NEWS file and see if
you are aware of any major features recently added that are
NEWS: Add notes for 0.5 release. Which is ready to go now.
2010-11-12 05:41:06 +01:00
not mentioned there. If so, please add them, (and ask the
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
authors of the commits to update NEWS in the future).
RELEASING: Change wording of libnotmuch version instruction 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.
2010-04-16 05:50:46 +02:00
2) Verify that the library version in lib/Makefile.local is correct
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Change wording of libnotmuch version instruction 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.
2010-04-16 05:50:46 +02:00
See the instructions there for how to increment it.
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Change wording of libnotmuch version instruction 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.
2010-04-16 05:50:46 +02:00
The version should have been updated with any commits that
RELEASING: update symbol handling description for current practice. 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
2011-11-16 12:21:35 +01:00
added API _in a non-upwardly compatible_ way, but do check
that that is the case. The command below can be useful for
inspecting header-file changes since the last release X.Y:
RELEASING: Change wording of libnotmuch version instruction 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.
2010-04-16 05:50:46 +02:00
git diff X.Y..HEAD -- lib/notmuch.h
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Change wording of libnotmuch version instruction 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.
2010-04-16 05:50:46 +02:00
Commit this change, if any.
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: update symbol handling description for current practice. 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
2011-11-16 12:21:35 +01:00
3) Update the debian/libnotmuchX.symbols file
add note about updating the debian symbols file to the RELEASE file
2011-05-05 18:38:38 +02:00
If the library version changed at all (step 2) it probably
means that symbols have changed/been added, in which case the
debian symbols file also needs to be updated:
dpkg-buildpackage -uc -us
RELEASING: update symbol handling description for current practice. 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
2011-11-16 12:21:35 +01:00
dpkg-gensymbols -plibnotmuchX | patch -p0
add note about updating the debian symbols file to the RELEASE file
2011-05-05 18:38:38 +02:00
Carefully review the changes to debian/libnotmuch1.symbols to
RELEASING: update symbol handling description for current practice. 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
2011-11-16 12:21:35 +01:00
make sure there are no unexpected changes. Remove any debian
versions from symbols.
add note about updating the debian symbols file to the RELEASE file
2011-05-05 18:38:38 +02:00
Commit this change, if any.
4) Upgrade the version in the file "version"
RELEASING: Add a step to upgrade the version in the "version" file. 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".
2010-04-16 19:58:53 +02:00
The scheme for the release number is as follows:
A major milestone in usability causes an increase in the major
number, yielding a two-component version with a minor number
of 0, (such as "1.0" or "2.0").
Otherwise, releases with changes in features cause an increase
in the minor number, yielding a two-component version, (such
as "1.1" or "1.2").
Finally, releases that do not change "features" but are merely
Increment notmuch version to 0.4. 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.
2010-11-02 00:16:03 +01:00
bug fixes either increase the micro number or add it (starting
at ".1" if not present). So a bug-fix release from "1.0" would
be "1.0.1" and a subsequent bug-fix release would be "1.0.2"
etc.
RELEASING: Add a step to upgrade the version in the "version" file. 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".
2010-04-16 19:58:53 +02:00
RELEASING: update discussion of version handling This is definitely reaching the point where it should be automated.
2011-11-16 12:25:57 +01:00
Update bindings/python/notmuch/version.py to match version.
Update the version in notmuch.1 to match version.
RELEASING: update description of "make release". 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.
2011-11-16 12:41:44 +01:00
XXX: Probably these last two steps should be (semi-)automated.
RELEASING: update discussion of version handling This is definitely reaching the point where it should be automated.
2011-11-16 12:25:57 +01:00
Commit these changes.
RELEASING: Add a step to upgrade the version in the "version" file. 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".
2010-04-16 19:58:53 +02:00
add note about updating the debian symbols file to the RELEASE file
2011-05-05 18:38:38 +02:00
5) Create an entry for the new release in debian/changelog
RELEASING: Add a (manual!) step to create a debian/changelog entry I'd like to have this be fully automated in the future, but for now, it's an extra step.
2010-04-16 19:23:50 +02:00
The syntax of this file is tightly restricted, but the
debian/changelog: Add notes for the 0.3 release Again, just taking the one-line entries from the NEWS entry for 0.3.
2010-04-27 11:07:45 +02:00
available emacs mode (see the dpkg-dev-el package) helps.
The entries here will be the Debian-relevant single-line
RELEASING: Add a (manual!) step to create a debian/changelog entry I'd like to have this be fully automated in the future, but for now, it's an extra step.
2010-04-16 19:23:50 +02:00
description of changes from the NEWS entry. And the version
must match the version in the next step.
Commit this change.
XXX: It would be great if this step were automated as part of
release, (taking entries from NEWS and the version from the
RELEASING: Add a step to upgrade the version in the "version" file. 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".
2010-04-16 19:58:53 +02:00
version file, and creating a new commit, etc.)
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
add note about updating the debian symbols file to the RELEASE file
2011-05-05 18:38:38 +02:00
6) Run "make release" which will perform the following steps.
make release: Add Debian package building and upload Finally, a single button to push to do all the uploading.
2010-04-16 22:13:12 +02:00
RELEASING: update description of "make release". 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.
2011-11-16 12:41:44 +01:00
Note: in order to really upload anything, set the make variable
REALLY_UPLOAD=yes
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Add a step to upgrade the version in the "version" file. 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".
2010-04-16 19:58:53 +02:00
* Ensure that the version consists only of digits and periods
make release: Add a check that version and debian/changelog are consistent 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.
2010-04-16 22:00:35 +02:00
* Ensure that version and debian/changelog have the same version
make release: Enforce a clean source tree before release. Where by clean, we check that no files are known to git to be modified.
2010-04-16 05:03:30 +02:00
* Verify that the source tree is clean
Makefile: Make "make release" run the test suite. This drops one manual step from our release process, (helping to ensure we don't forget anything during the release).
2010-04-16 01:08:37 +02:00
* Compile the current notmuch code (aborting release if it fails)
* Run the notmuch test suite (aborting release if it fails)
make release: Enforce a clean source tree before release. Where by clean, we check that no files are known to git to be modified.
2010-04-16 05:03:30 +02:00
* Check that no release exists with the current version
RELEASING: update description of "make release". 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.
2011-11-16 12:41:44 +01:00
* Make a signed tag
* Generate a tar file from this tag
* Generate a .sha1 sum file for the tar file and GPG sign it.
* Commit a (delta for a) copy of the tar file using pristine-tar
* Tag for the debian version
* if REALLY_UPLOAD=yes
- push the signed tag to the origin
XXX FIXME push debian tag
- scp tarball to web site
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
* Provide some text for the release announcement (see below).
add note about updating the debian symbols file to the RELEASE file
2011-05-05 18:38:38 +02:00
7) Send a message to notmuch@notmuchmail.org to announce the release.
RELEASING: Add this file describing the steps to make a release. These steps might be changing a bit as we work on making the initial 0.1 release.
2010-04-06 00:00:37 +02:00
RELEASING: Update instructions for new version technique. We pass this in on the "make release" command-line rather than editing the Makefile.
2010-04-10 04:12:36 +02:00
Use the text provided from "make release" above, (if for some
reason you lose this message, "make release-message" prints
it again for you.
Reference in a new issue Copy permalink