Sorry, I should have changed the subject line on this. -ian
On Tue, 2004-08-17 at 10:08 -0500, Ian Murdock wrote:
> On Mon, 2004-08-16 at 14:58 -0500, Jeff Licquia wrote:
> > 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).
>
> Excellent idea. Consider this CL policy. Applies to Discover too.
--
Ian Murdock
317-578-8882 (office)
http://www.progeny.com/
http://ianmurdock.com/
"If they give you ruled paper, write the other way." --Juan Ramón Jiménez
|
