Date: Sat, 19 Jan 2002 17:56:15 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: <iedowse@FreeBSD.org> Cc: freebsd-bugs@FreeBSD.org Subject: Re: conf/6346: Kernel version strings need to relate to the source not the build Message-ID: <200C680F-0D38-11D6-AFF7-0003930737AC@dataplex.net> In-Reply-To: <200201192202.g0JM2ou69294@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, January 19, 2002, at 04:02 PM, <iedowse@FreeBSD.org> wrote: > Synopsis: Kernel version strings need to relate to the source not the > build > > State-Changed-From-To: open->feedback > State-Changed-By: iedowse > State-Changed-When: Sat Jan 19 14:00:25 PST 2002 > State-Changed-Why: > > Can this be closed? Since there are so many ways of updating the > source, I'm not sure that a `source date' in the version string is > practical. The point that I made is still valid. Since users can, and often do, update their source tree between releases, the Release number is inadequate to identify which version they have. We need some measure of the incremental updates which have been applied. For example, the ctm update number uniquely identifies a source image. However, that mechanism is not presently available in all of the distribution paths. The date on the kernel does give some measure of the state of the sources used to build the system. However, it is really just an upper bound. The sources that are used are somewhat older. The mechanism by which someone updates their tree is generally unimportant. Their tree becomes a snapshot of the master tree. The thing that matters is when that snapshot was taken, not how it was transported, when it arrived, and certainly not when it is used to build a system. If I were to get a source image from, for example the 4.3 Release CD, the system that I build from that source today is really "older" than a 4.4 system that was built last September. Further, it does not contain the changes which were made in December. In this extreme case, the Release number would have changed and that would be a clue. However, we are often looking for a finer granularity. As a result, IMHO, we need a mechanism to attach a date to the source before it is distributed, and NOT use the build date to attempt to proxy this sub-release versioning. If the label is introduced at the origin, the process of updating the sources by any of the access paths will propagate that date label as it was contained in the original master repository at the time that the snapshot was taken. -- Richard Wackerbarth The Digital Dataplex (512) 346-5772 8801 Camelia Ln rkw@dataplex.net Austin, TX 78759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200C680F-0D38-11D6-AFF7-0003930737AC>