Rant on controlled migration [was: Changing security parameters]

[David Collier-Brown]

  To oversimplify, if you can make an old Samba parameter
take up a distinguished "does not apply" value when 
queried or used, and if you can add new parameters, you can
update the consumers of the parameter, the clients,
independently of the producer of the parameter, the
server.
  This corresponds to databases having null values and
allowing addition of new columns to relations, respectively.

This in turn is the necessary-and-sufficient part (but not
the laborious part) of allowing asynchronous development
and maintenance.

The laborious part is writing the old-to-new and new-to-old
interface helper-functions, introducing them at the
right time, making them produce the right error
messages and retiring them at the right time.  

---
Concrete proposal re the labourious part:
	Introduce the new parameters in 2.x, map it
	to the security=x implementation, warn loudly
	if it's used wrong, mention quietly if it's
	used right.

	Mention quietly if other parameters are
	inconsistant with the values set (eg, auth 
	server set with auth order = unix)

	Put the new code into service in a late 2.x
	**development** release, providing
	compatability.

	Phase compatability out starting with 3.0:
	in 3.0.0, warn loudly if compatability used,
	in 3.1.0 diagnose and halt.


--dave  
-- 
David Collier-Brown,           | Always do right. This will gratify 
Americas Customer Engineering, | some people and astonish the rest.
SunPS Integration Services.    |                      -- Mark Twain
(905) 415-2849                 | davecb at canada.sun.com