[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Version to use in package for a program with non standard versioning

As of November 2005, I've picked up maintainance of qd, the Folding@Home
queue dumper, after it's author passed away in August 2005.

I'm trying to create native Debian packages for qd, it's data file
(qdinfo.dat) and another program to print the content of the data file

qd and qdiprint, are both a single .c file, without a configure or
anything else, qdinfo.dat is a text file with credits per project tables.
Up to now, only the .c files and precompiled binaries were available on
the authors website. Since then I've been writing some documentation,
besides a few bugfixes, which are now also available.

qd is already packaged for Debian by Claudio Moratti, and I've spoken with
him about my intent to package the more up to date version qd. He doesn't
mind and will switch his kfolding package over to depend on my qd package
when/if it's hits the archive.

Now for the problem I'm dealing with. qd doesn't use traditional
versioning, it uses two values for it's version.

The first value is the date on which it's internal pointtable was created,
this point table has the same data as the qdinfo.dat file has. The
qdinfo.dat files was created so that it wasn't needed to download and/or
compile a new binary if only its credits per project table was updated.
The qd binary uses this date to check if its internal pointtable is more
recent than the pointtable provided by the qdinfo.dat data file.

Secondly it has a "functional revision", this is a 3 decimal number,
currently at 033, which is the actual version of the code. Whenever there
was a bugfix, a new feature or change in the programs behaviour the
functional revision was incremented. The most recent "functional revision"
is also noted in the qdinfo.dat file, so that when only the qdinfo.dat is
updated, the user will be notified that a new release of qd is available.

If I look at Section 2.3 of the New Maintainers Guide, it says I should
use whatever non-standard versioning is used prefixed with "0.0.".
Thinking in the Debian way of keeping your packages up to date, I'm not
sure which version I should use here, and if I should change the way
update notification is currently handled.

I was thinking that the functional revision would be best to use in the
package version, because this effects the programs functioning. New
functional revisions would mean a new upload of an updated debian package.
In the meantime updates to the point table, which can be daily changes,
other times there are no changes for more than a month, will be done
through qdinfo.dat as usual. I was thinking of either a volatile package
for qdinfo.dat, or a separate script to download an updated version.

How does the version string effect a Debian package? Would this work?
Would it be wise for me to also include the date of the point table inside
the qd binary in the version string for the qd package?

Currently I have qd-0.0.033, qdinfo-0.0.20051226 and qdiprint-0.0.3.
qdiprint doesn't have any versioning whatsoever, therefor I now keep my
own in the traditional x.y.z format.



Reply to: