On Fri, Jul 21, 2006 at 09:27:23PM +0200, Michael Buesch wrote:
> What is a major change? Why only on major change? Why not on
> simple changes, too? Simple changes sometimes introduce bugs, too.
the version number has whatever meaning you choose to assign to it.
Including none, if you so choose.
On Friday 21 July 2006 21:13, Jason Lunz wrote:
> On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> > I am not going to maintain a bogus version number.
> > What about simply returning 1.0 and be done with it.
> > I don't think it matters. 1.0 is as bogus as any other value.
>
> Pu
On Fri, Jul 21, Michael Buesch wrote:
> On Friday 21 July 2006 20:59, Olaf Hering wrote:
> >
> > bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
> > driver version. I think this specific info can be obtained by other
> > ways.
> > Can you give bcm43xx a real version number an
On Fri, Jul 21, 2006 at 09:03:23PM +0200, Michael Buesch wrote:
> I am not going to maintain a bogus version number.
> What about simply returning 1.0 and be done with it.
> I don't think it matters. 1.0 is as bogus as any other value.
Put it to use! Increment it whenever there's a major change in
On Friday 21 July 2006 20:59, Olaf Hering wrote:
>
> bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
> driver version. I think this specific info can be obtained by other
> ways.
> Can you give bcm43xx a real version number and provide it via the
> ethtool ioctl?
I am not goin
bcm43xx_get_drvinfo in 2.6.18-rc2 unfortunately uses UTS_RELEASE as
driver version. I think this specific info can be obtained by other
ways.
Can you give bcm43xx a real version number and provide it via the
ethtool ioctl?
It will trigger a rebuild if the uname -r of the kernel to build
changes.
-
