Deleting parameters.

[Herbert Lewis]

David Brodbeck wrote:
> 
> What would be really great (though is seldom done in most software, in my
> experience) would be if, instead of just spitting the old parameters back as
> syntax errors, the error log would give some clue as to where to look for
> the new ones.  (e.g., "Parameter 'security' is no longer supported, see
> 'server role'.)

As the person that has to maintain the supported version of Samba for
IRIX
this has a direct impact on me. 

I tend to agree with Andrew that new major releases are the only chance
we have to really clean things up on an interface level. We do have
a precedent for removing parameters even in minor releases (share
modes).

While it does present problems when options disappear and people do not
read the release notes (you will always get those type of people) this
can be handled by fixing testparm. We could add a new flag that only 
spits out unknown parameters with the above type of message telling the
person where to look for the replacement functionality. This could be
run as part of the install process if there is an existing smb.conf
file. The output from the existing testparm is just too verbose for
this kind of check and important things might get missed.

Every time I teach a course on Samba I try to get people used to the
"real" parameter name and not use aliases. If you allow SWAT to rewrite
your smb.conf it will automatically change any alias to the "real"
name. If people are not aware of the aliases they may get confused
when they see their smb.conf changed and their favorite parameter
just disappeared. I think a new major release may be a good chance
to reduce the number of confusing aliaes as well.

So the bottom line for me is that it is OK to change the interface 
for a major release as long as it is well documentated what has 
changed and what you need to do to maintain the same functionality
when you upgrade.

my 2 cents

herb