On 06/12/09 12:42, James Carlson wrote: > Huie-Ying Lee writes: > >> I can change the relevant lines as below, if that looks better. >> >> #Port forwarding >> #AllowTcpForwarding yes >> > > I think it's a little less surprising that way, so I prefer it, but > now that I understand the project a good bit better, it's not a > significant issue. > > Glad to know this is no longer a big issue. >>> Why not just change the way it installs, so that it installs as >>> "AllowTcpForwarding yes" by default, and leaves it unchanged on >>> upgrade or patch? >>> >>> >>> >> Right, that's our goal also. What would be the right release binding ? >> > > Patch/micro is the right release binding. What's missing is the > description of how the delivery will work. Something like this: > > Since we're changing a default value, and we want to avoid > suprise on upgrade, and since we can't tell whether a user has > intentionally configured the "no" value or whether it was just > left at the default, we will do the following for the patch > delivery: > > - If the system is initially installed from freshbitted > packages containing this change, then the system will have > AllowTcpForwarding set to "yes" by default. The release > notes for the release containing this change will note the > difference. > > - When upgrading or patching an existing system (installed > before this fix was introduced), the AllowTcpForwarding > value will not be changed. A release note (for the update > release) and README for the patch will be included to tell > users what to do if they want the new value. > > Thank you for the suggestions.
This change is intended for Nevada only, which I didn't mention clearly in the spec file. (sorry!) The release binding should be "minor", if it is for Nevada only. Correct ? Do we still need to have a description of how the delivery will work, if the release binding is "minor" ? Do we need to submit an updated spec file ? Thanks, Huie-Ying
