On Saturday, December 03, 2005 01:26:57 AM -0500 Jeffrey Altman <[EMAIL PROTECTED]> wrote:
One of the points that I am attempting to make is that the rate of change in the Windows client is going to continue to out pace the rate of change in the Unix-based implementations for at least the next year as it continues to play catch up. During this time there is going to be a significant impact on end-users with new user interfaces and behavioral experiences depending on which client the user chooses to install.
Great. Adding significant new functionality and making major behavioral changes is what the unstable branch is for. The stable branch is for being stable.
Prior to the release of OpenAFS 1.4.0, we essentially forced Windows users to run the unstable branch if they didn't want something that was horribly buggy and crashed a lot. That was unfortunate, but necessary.
Now we _have_ something that's not horribly buggy and doesn't crash a lot. As we discover and correct new bugs, those fixes should be applied to the stable branch. However, users who want these fixes should no longer be forced to run a constantly-changing unstable version in order to get them. Make major changes on the unstable branch. People who want significant new functionality which hasn't been heavily tested and violates the principle of least surprise get to run the unstable version -- that's what it's _for_.
The way I rationalize it is that the OpenAFS version number is tied to a set of functionality implemented in the servers. As long as the server functionality does not change in a significant manner, the version number will not be bumped.
Rationalization indeed. So, you feel you can make whatever radical changes you want to the client as long as there's not significant new server functionality? I'm sorry Jeff, but "stable" means the _whole thing_ is stable, not the whole thing except the part you feel like completely rewriting.
what incentive is there for you to upgrade your users to 1.4.1 as opposed to 1.4.0? The bugs in the 1.4.0 client are so minor that simply obtaining a fix for those bugs if you are not actively experiencing them is not a reason to upgrade.
And if you are experiencing them, you should not be required to submit to a major functionality change to make the problem go away.
OpenAFS for Windows sucked for a long, long time. You've spent a lot of time and effort making it stable enough for production use. Now that we've reached that point, it's time to distinguish strongly between the version people _run_ in production use, and the version with all the fancy new features. We can no longer afford to shove major changes down people's throats that they aren't ready for.
-- Jeff _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
