Lintian::Collect, version numbering
As previously discussed on the list, I've added a new framework for
handling data collection about packages. Currently, the functionality is
fairly limited, but the infrastructure is now in place and we can start
growing it.
Every check script now gets a third argument, which is a Lintian::Collect
object (well, actually either a Lintian::Collect::Source object or undef
right now, but eventually a Lintian::Collect::Source,
Lintian::Collect::Binary, or Lintian::Collect::Udeb object, all of which
inherit from Lintian::Collect). The idea is that any code that reads data
from the lab should instead call methods in those objects, which abstracts
out the interface to the lab.
The main immediate benefit is that the methods in the Lintian::Collect
objects will cache data in memory, so the twenty times that we read
fields/version while checking one package will become only one file read
and then memory accesses. However, down the road, this opens the
possibility of doing away with the collect scripts if we want to and just
using this object to hold the same data.
There is POD documentation for the new modules; take a look and let me
know what you think.
Given that this is an infrastructure change, I think this warrants a
version bump, and I'd like to propose that we change the version numbering
of Lintian at the same time. Currently, all we're ever doing is
incrementing the third version number of the package. Should we switch to
just using two versions; in other words, make the next version 1.24, the
version after that 1.25, and so forth? Then we can do major version bumps
for backward-incompatible changes or for major changes (such as,
hopefully, the summer work on tag classification).
What do people think?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: