On 11/30/2009 07:35 AM, Ben Hutchings wrote:

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

quoted

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.

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.

Sounds like kernel version it is.  Will debut ethtool-2.6.33 in a week 
or so, then.  I posted ethtool-2.6.33-pre1 just now (intentionally 
different from 2.6.33-rc1, to hint that ethtool release candidates need 
not march in lock step with kernel pre-releases).  Let some bug fixes 
trickle in, and then release ethtool-2.6.33.

	Jeff