On Sun, 2009-11-29 at 05:42 -0500, Jeff Garzik wrote:
[...]

I've been trying to think of what would be a good versioning scheme for 
ethtool.  Even though it is [essentially] a user-friendly kernel 
interface, its releases have never really been closely synchronized with 
the kernel releases.  And unlike a lot of other software, ethtool is so 
simple it does not really go through any release-candidate or beta period.

The current scheme just increments a release number: 5->6, 6->7, etc. 
But with so few kernel releases (and thus ethtool releases), I was 
leaning towards either yearly release naming ("ethtool-2009"), kernel 
release naming ("ethtool-2.6.33"), or the release scheme proposed for 
glibc:  snapshot directly from the git repository.

If people want one, I could do a release right now.  Or, we could move 
to an alternate scheme like git snapshots.  I think git snapshots are 
viable because ethtool has historically had next to zero bugs in the 
actual userland utility.  Fedora already imports git snapshots, for example.

So does Debian.  But this is because we need to include the new
features, not because we like using snapshots.

Preferences?

I think it should be based on kernel versions, so that it's clear
whether a given ethtool version supports the features introduced in a
given kernel version.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.