debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-26 12:55:18 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/RELEASING

80 lines
3.2 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
not mentioned there. If so, pleas add them, (and ask the
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
added API, 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:
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
Note: We currently don't plan to increment
LIBNOTMUCH_VERSION_MAJOR beyond 1, so if there *are*
incompatible changes to the library interface, then
stop. Don't release. Figure out the plan on the notmuch
mailing list.
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: 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
3) Create an entry for the new release in debian/changelog
The syntax of this file is tightly restricted, but the
available emacs mode (see the dpkg-dev-el package helps). The
entries here will be the Debian-relevant single-line
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
VERSION, and creating a new commit).
4) Run "make VERSION=X.Y release" which will perform the following steps:
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
For the X.Y version, we'll generally just increment Y. But for
major milestones of usability we're increment X as well.
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
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
* Ensure that the caller passed VERSION=X.Y
* 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)
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
* Generate the final tar file
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
* Generate a .sha1 sum file for the tar file
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
* Sign the sha1sum using your GPG setup (asks for your GPG password)
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: 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
* scp the three files to appear on http://notmuchmail.org/releases
* Create a LATEST-notmuch-version file (after deleting any old one)
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
* Place local copies of the three files in the releases directory
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
* Tag the entire source tree with a tag of the form X.Y.Z, and sign
the tag with your GPG key (asks for your GPG password, and you
may need to set GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL to match
your public-key's setting or this fails.)
Makefile: Make the "make release" target push the new tag. Otherwise I'm sure I'll always forget to push it.
2010-04-06 00:56:23 +02:00
* Push that tag
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).
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
5) 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