Re: HEADS-UP new statfs structure

From: M. Warner Losh <imp_at_bsdimp.com>
Date: Sat, 15 Nov 2003 23:21:57 -0700 (MST)
In message: <Pine.GSO.4.10.10311160015450.12372-100000_at_pcnet5.pcnet.com>
            Daniel Eischen <eischen_at_vigrid.com> writes:
: On Sat, 15 Nov 2003, Marcel Moolenaar wrote:
: 
: > On Sat, Nov 15, 2003 at 02:45:57PM -0800, Terry Lambert wrote:
: > > 
: > > > For 6.0, can we start off libc at libc.so.YYYYMMDD and move it
: > > > back to libc.so.6 for the first release?  That way we can bump
: > > > it whenever we want to avoid the "bumpy" rides for -current
: > > > folk.
: > > 
: > > This is a great idea!
: > 
: > Provided that we
: > 1. keep the major number to allow concurrent development of different
: >    (major) library versions, and
: > 2. replace the date with a convenient sequence number, which we can
: >    call the minor version number, and
: > 3. Do not reset the version number when we release.
: > 
: > E.g.: libc.so.6.0, libc.so.6.1, and (first release) libc.so.6.2...
: 
: I don't care so much about naming conventions.  It would just be
: nice to be able to bump the version in development as often as
: you like without usurping release version ids (major or minor).
: You can still use minor numbers while still not throwing some away:
: 
: 	6.0 Branch - libc.so.6.1000
: 	    libc bump - libc.so.6.1001
: 	    libc bump - libc.so.6.1002
: 	6.0-Release - libc.so.6.0
: 	    libc bump - libc.so.6.1003
: 	6.1-Release - libc.so.6.1
: 	...

Please no.  ELF libraries have no minor numbers and a scheme like this
would likely cause no end of problems.  For FreeBSD 6.x we should keep
the same API and actively pursue people that want to break it with
large pointy sticks.

Warner
Received on Sat Nov 15 2003 - 21:22:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:29 UTC