On Sun, 2004-08-15 at 05:56, John wrote:
> Ian Murdock wrote:
>
> >In the future, we need to make sure the version numbers used in
> >changelog entries reflect the fact that the current version hasn't
> >been released yet (e.g., "picax (1.5pre1)", with a monotonically
> >increasing "pre" number for each change, which would then become
> >"picax (1.5)" when picax 1.5 is released). Also, when new versions
> >are released, those new versions should be placed
> >in the cl-devel component and on archive.p.c in /progeny/anaconda.
>
> Why not anaconda-10.0-1.4446 and so on? Anone can build a deb from svn
> and get the matching version.
That could work, as long as we released like this:
foo-0.0-0.4447
foo-0.0-0.4448
...
foo-0.0-0.4458
foo-1.0-1
foo-1.0-1.4461
foo-1.0-1.4462
...
foo-1.0-1.4487
foo-1.1-1
foo-1.1-1.4491
and so on. In other words, bare revisions w/o subversion version tags
are the oldest.
The main problem I see here is keeping up to date. What happens if you
forget to update the changelog?
Here's what I recommend:
- Use $Revision$ in debian/changelog, like so:
foo (1.0-1.$Revision$) unstable; urgency=low
- Always add a note to debian/changelog when adding features. We
should be doing that anyway. This will trigger $Revision$ (which only
gets the last revision in which the file was changed).
|
