scsh-users
[Top] [All Lists]

attn sunterlib contribs: version numbers

To: scsh <scsh-users@scsh.net>
Subject: attn sunterlib contribs: version numbers
From: Anthony Carrico <acarrico@memebeam.org>
Date: Fri, 4 Jun 2004 00:31:57 +0200 (MST)
List-id: <scsh-users.list-id.scsh.net>
Remember that each subpackage is administrated by its authors. In
particular, please remember to bump your version numbers before you
make your changes (within a new sunterlib version). Sorry, but that is
life in a package of packages. The nice thing about the policy is
that, in theory, only those libraries that actually change will have
new versions when a new sunterlib is released.

README.contrib says, "To avoid releasing different versions under the
same number, if the Sunterlib version has changed, then bump the local
version number before changing your library. Remember to keep the
local NEWS file up to date with your library. Remember to keep the
version number up to date with your package definition."

The release procedure in README.admin always tags sunterlib releases,
so when in doubt, you can check those to see if you have broken the
rule, for example see:
  
http://savannah.nongnu.org/cgi-bin/viewcvs/sunterlib/sunterlib/scsh/tiff/pkg-def.scm

The first library to fall into this trap was tiff. I was about to do
an "msdos accomodation" release for the aux.scm issue, and I realized
that tiff's pkg-def.scm and NEWS version numbers had not been bumped.
This would have stomped old installations, and left a bogus aux.scm
around.

Note that the top-level of sunterlib autogenerates its pkg-def.scm,
and inserts the proper version. The Makefile should go one step
further and extract that version from NEWS (so there is a single
source for the version number). This might be the way to go for
subpackages, so feel free to create a Makefile for your subpackage
(and to call out to it from the top-level Makefile). If someone
figures out a nice standard method to solve the problem, then let us
know in README.contrib.

I apologize for this issue, and I'm afraid it might become a
persistant problem. We need a script to test for violations (so we can
catch them before a release).

TODO:

1.7 whuffies to the first person to write a reliable script to extract
the latest version (a list of numbers) from our NEWS format.

3.1 whuffies to the first person to write a script to test subpackages
for version problems (perhaps by diffing two distribution tar files).

Keep up the good work!

-- 
Anthony Carrico
http://giftfile.org

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>
  • attn sunterlib contribs: version numbers, Anthony Carrico <=