aboutsummaryrefslogtreecommitdiffhomepage
path: root/version
Commit message (Collapse)AuthorAge
* update version to 0.12Gravatar David Bremner2012-03-19
| | | | There may be a few NEWS changes after this, but no code (hopefully).
* bump version to 0.12~rc2Gravatar David Bremner2012-03-18
|
* bump version to 0.12~rc1Gravatar David Bremner2012-03-01
| | | | | As usual, only `version' is edited by hand. The rest of the changes I blame on the machine.
* version: bump to 0.11.1Gravatar David Bremner2012-02-03
| | | | also semi-automatically update man page and python bindings versions.
* Update version to 0.11Gravatar David Bremner2012-01-13
|
* version: update to 0.11~rc3Gravatar David Bremner2012-01-09
| | | | We found another serious-ish bug during freeze.
* version: bump to 0.11~rc2Gravatar David Bremner2012-01-02
| | | | This to "celebrate" pushing a bugfix in at the last minute.
* version: update version to 0.11~rc1Gravatar David Bremner2011-12-25
| | | | and keep python, man page, and debian package in sync.
* version: bump for bugfix release 0.10.2Gravatar David Bremner2011-12-05
|
* version: update to 0.10.1Gravatar David Bremner2011-11-25
|
* version: update to 0.10Gravatar David Bremner2011-11-23
|
* version: update version info for 0.10~rc2Gravatar David Bremner2011-11-19
| | | | | Arguably editing debian/changelog violates the "do one thing at a time" rule, but all of these versions need to be kept in sync.
* version: update to 0.10~rc1Gravatar David Bremner2011-11-15
| | | | and the usual dance with the python bindings version.
* version: bump to 0.9Gravatar David Bremner2011-10-11
| | | | also bump python bindings version.
* version: bump to 0.9~rc2Gravatar David Bremner2011-10-07
| | | | We continue to keep the python bindings version in sync manually
* version: bump to 0.9~rc1Gravatar David Bremner2011-09-24
| | | | | This version number change should not be taken as definitive, rather refer to the signed tag.
* update versions for release 0.8Gravatar David Bremner2011-09-10
| | | | See commit 6979b65 for more discussion.
* update versions for release candidateGravatar David Bremner2011-09-06
| | | | | | | | | | we now have three files to keep in sync. That seems wrong, but I guess we will live with it for now. The main problem is that the python code is distributed separately, so it can't get the version from 'version'. The choice ~rcX is for convenience with debian versioning.
* version: bump to 0.7Gravatar David Bremner2011-08-01
| | | | No actual changes since 0.7~rc1
* bump upstream version to 0.7~rc1Gravatar David Bremner2011-07-29
|
* version: bump to 0.6.1Gravatar David Bremner2011-07-17
|
* version: bump to 0.6Gravatar David Bremner2011-07-01
| | | | | The release machinery in the build system depends on this file being correct.
* Increment notmuch version to 0.5Gravatar Carl Worth2010-11-11
| | | | | | | | The big change here is the support for maildir-flag synchronization. But there are a number of other thigns as well---library support for multiple filenames, new ruby bindings, improvements to the vim interface, and a few tweaks to the emacs interface.
* Increment notmuch version to 0.4.Gravatar Carl Worth2010-11-01
| | | | | 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.
* Increment version to 0.3.1Gravatar Carl Worth2010-04-27
| | | | For our 0.3.1 bug-fix release.
* Increment package version to 0.3.Gravatar Carl Worth2010-04-27
| | | | For the 0.3 release, of course.
* Increment version to 0.2.Gravatar Carl Worth2010-04-16
| | | | Only minor features added this time--nothing that merits a 1.0.
* Makefile: Add an explicit version file to the repository.Gravatar Carl Worth2010-04-16
We do this so that "git archive" produces a usable tar file without us having to post-modify it, (since tools like git-buildpackage might not give us an easy way to hook into the tar-file-creation step). To support this we also have to change our preference to prefer the git-described-based version (if available) and only if not available do we fallback to using what's in the "version" file. Finally, we also ovverride this preference when releasing, (where what's in the "version" file wins). Note that using our Makefile's rule to create a tar file still will insert the git-based version into the tar file. This is useful for creating snapshots which will correctly report the git version from which they were created.