notmuch - thread-based email index, search and tagging

	Commit message (Collapse)	Author	Age
*	debian/changelog: Add notes for the 0.3 release	Carl Worth	2010-04-27
\| \| \| \|	Again, just taking the one-line entries from the NEWS entry for 0.3.
*	make release: Add Debian package building and upload	Carl Worth	2010-04-16
\| \| \| \|	Finally, a single button to push to do all the uploading.
*	make release: Add a check that version and debian/changelog are consistent	Carl Worth	2010-04-16
\| \| \| \| \| \| \|	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.
*	RELEASING: Add a step to upgrade the version in the "version" file.	Carl Worth	2010-04-16
\| \| \| \| \| \|	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".
*	RELEASING: Add a (manual!) step to create a debian/changelog entry	Carl Worth	2010-04-16
\| \| \| \| \|	I'd like to have this be fully automated in the future, but for now, it's an extra step.
*	RELEASING: Change wording of libnotmuch version instruction	Carl Worth	2010-04-15
\| \| \| \| \| \| \|	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.
*	make release: Enforce a clean source tree before release.	Carl Worth	2010-04-15
\| \| \| \| \|	Where by clean, we check that no files are known to git to be modified.
*	RELEASING: Remove a meaningless step from the release process.	Carl Worth	2010-04-15
\| \| \| \| \| \| \| \| \| \| \|	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).
*	RELEASING: Remove obsolete step about updating micro version number.	Carl Worth	2010-04-15
\| \| \| \| \| \| \|	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.
*	Makefile: Make "make release" run the test suite.	Carl Worth	2010-04-15
\| \| \| \| \|	This drops one manual step from our release process, (helping to ensure we don't forget anything during the release).
*	RELEASING: Update instructions for new version technique.	Carl Worth	2010-04-09
\| \| \| \| \|	We pass this in on the "make release" command-line rather than editing the Makefile.
*	Makefile: Print template for release announcement.	Carl Worth	2010-04-05
\| \| \| \| \|	At the end of "make release" or at any point later with "make release-message".
*	Makefile: Make the "make release" target push the new tag.	Carl Worth	2010-04-05
\| \| \| \|	Otherwise I'm sure I'll always forget to push it.
*	Makefile: Start implementing a "make release" target.	Carl Worth	2010-04-05
\| \| \| \| \|	So far just doing checks that the version is sane and that no release of the same version already exists.
*	RELEASING: Add this file describing the steps to make a release.	Carl Worth	2010-04-05
	These steps might be changing a bit as we work on making the initial 0.1 release.