[OpenAFS] Re: "OpenAFS for Windows development road map" was Re: [OpenAFS]
1.4.1-rc2 build question
Mon, 05 Dec 2005 02:52:33 -0500
On Saturday, December 03, 2005 01:26:57 AM -0500 Jeffrey Altman
> 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
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
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
> 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.