On Tue, 28 Aug 2007, John Baldwin wrote:
> I think this is dead on, yes. Only comment I would add is that I think
> the "flag days" should be when a new RELENG_X is branched and that all the
> FBSD-current shims get tossed in the RELENG_X branch. The FBSD-current shims
> can be dropped from HEAD on a separate schedule, maybe where they get dropped
> after they've been around for 6 months or so. This does mean that stepping
> off -CURRENT onto RELENG_X requires a rebuild of your ports for any symbols
> that changed since RELENG_X-1, but I think that is tolerable.
The only thing I would add is that we can do this by using the
real public versions in -current instead of private ones only
seen in current. By using the public versions, -current users
will never have to rebuild any of their ports _unless_ the
same ABI changed more than once in -current, and that has
never happened in the past. If it does happen, you can
remove interim versions from RELENG_X at the branch, and
then remove the interim version from -current some time later.
This is the same approach as using a "private in current"
version namespace. The only disadvantage is that you might
be missing a version or two in RELENG_X if you remove an
interim FBSD_1.4 for instance.
The other problem with the private version namespace thing
is that it doesn't allow for MFC'ing an ABI change to RELENG_X.
It also causes you to change a lot of files (Symbol.map files,
source files with compat shims) whenever you have the flag
day and move from FBSDcurrent_1.x to FBSD_1.1.
It is so much more simpler to use the same versioning in
-current as for releases. It is easier to MFC, doesn't
cause unneeded changes to Symbol.map files and compat shims,
doesn't cause -current users to rebuild ports after flag
day (unless there are overlapping ABI changes), and still
provides everything that using the private version namespace