On Tue, 15 Apr 2003, John Franklin wrote:

> On Sat, Apr 12, 2003 at 09:46:05AM +0200, Jaromir Dolecek wrote:
> > Greywolf wrote:
> > > That's a pretty lax call; I'd say that anything which affects kernel
> > > structures changing AT ALL, let alone on a significant level such as,
> > > oh, say, FILE SYSTEM STRUCTURE CHANGES, warrants a kernel indicator.
> >
> > It does not affect general kernel structures. It affects code
> > for one file system, in that fs specific code. Would we bump kernel
> > version whenever random filesystem gets improved significantly?
> > We did not for LFS, and there is no reason to do for FFS/UFSv2, IMHO.

It's more than just an improvement -- the API changed in such a way
that "lsof" can't be built, and "lsof" uses __NetBSD_Version__, so,
even assuming "lsof" is fixed eventually (for __NetBSD_Version >=
1061800), it will still never build on NetBSD 1.6Q-1/2.

> Apparently not, but we should.  It was my understanding that whenever
> kernel APIs or structures change, the letter gets bumped.  IMHO, we
> should do it for FFS, we should do it for LFS, heck we should do it for
> NTFS, even though only a scant few ever use it!
>
> Be liberal with the letter bumps.  We have plenty of letters, and if we
> get into 16AA, 16AB, 16AC... so be it.  It's better to have too many
> than to not know when something changes.

There's only two digits for that in __NetBSD_Version__, but still that
gives 99, or up to something like 1.6ZZZU, so there seems to be enough
room to bump for API changes.

Frederick