> The whole "Stable Branch" thread on -security gave me an idea that's been
> perculating for some time.
>
> Problem:
> We have security problems in (say) -STABLE. They get fixed. We post an
> advisory about it, giving correction dates for -STABLE and -CURRENT, and
> the associated cutoff in which releases are fixed and which are not.
> However, tracking dates on buildworlds etc is hard. I'm sure I'm not
> the only one who usually does build/installworlds on source at least a
> week old. I check it it, built it, and if it's clean, wait to see if
> anyone else has any problems with it. And since I tend to put off building
> the kernel until I install, the date uname gives isn't necessarily useful
> for checking this sort of stuff.
>
> Idea:
> In the version string (or maybe somewhere else convenient), start adding
> codes at each -RELEASE along a branch. So, say we find a bug in fingerd.
> It's in 4.1-RELEASE, fixed in 4.1-STABLE at some point, and fixed in
> 4.2-RELEASE. We could add an 'a' to the version string in -STABLE, so it
> will read out as "4.1-STABLE a". Find another bug and fix it, we have
> "4.1-STABLE b". Presumably, this would only apply to such things as
Why not just use a date? I do this on most of my systems. My `uname
-r` reads:
4.1-20000916-STABLE
I started doing this for the exact same reason you described above--to
know when I updated the system. It does clutter the `uname -a` output
a bit, so it could be done similar to the way you suggested with the
flag: "4.1-STABLE 20000916".
Just a thought.
Regards
--
Dima Dorfman <[EMAIL PROTECTED]>
Finger [EMAIL PROTECTED] for my public PGP key.
It's kind of fun to do the impossible.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
