Jeffrey Hutzelman wrote:
How are you going to decide? I assume you are going to say to your users "now use version X.Y.Z".On Saturday, December 03, 2005 01:26:57 AM -0500 Jeffrey Altman <[EMAIL PROTECTED]> wrote:* Jan 2006 - Stable Windows client with byte range locking that is mandatory to useI have a better idea. I'll decide when byte-range locking support is mandatory for my users to use. I can think of no maintainability reason to remove the ability to operate under the old model, and frankly it's inappropriate for you to shove "you must use this feature" down my throat, especially on an agressive timeframe (and yes, 6 months is agressive for this large a change), and especially within the 1.4.x branch.
If you read my note carefully you would understand one of the problems associated with tying the version numbers across multiple platforms to one another. Different platforms are going to have different levels of stability. I agree with you that 1.4.0 is a very stable client on Windows. It is not a stable client on MacOS X 10.4 because there is no support for that platform. What version number should the MacOS X 10.4 release get? We are going to use 1.4.1 because it is the next version number in the Stable branch on the other platforms are not changing all that much but they are changing because the MacOS X merge was fairly large.
I've given you a road map of independent features. Should they wait until all new features described are available? If so, that doesn't meet the needs of those who are funding the development. Should Windows start its own version numbering system that is independent of the Unix world? We are after all talking about version numbers. You want to be able to distinguish between the versions you want your users to run and those you don't want them to run. Should Windows introduce 1.6 for Byte Range Locking? 1.8 for 64-bit Windows? 1.10 for Unicode/Large File support? Would having separate version numbers on the different platforms make it easier for you or is it going to make things more confusing?
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
