|Hey, the process can always change. :) I was mostly just |guessing given the circumstances, and knowing that Netapp |wouldn't not include the patch without a reason. | Bruce, Change is coming. Hopefully for the better but you can be the judge of that. Netapp is moving to a new software release model. This is motivated by a need to correct some of the deficiencies in our current model. Also, as our customer base continues to grow we believe we need a more scalable and predictable approach to patch and maintenance releases.

Let me give you a brief summary of the current model and where we are going with this new process. In the past, engineering was responsible for major and minor features releases. These releases went through the full engineering development and QA process. The customer engineering (CS) team had responsibility for the P releases and D patches. D patches were generated to fix a specific customer reported problem. P releases were a roll-up or collection of D patches that were judged to be valuable to a larger set of customers. For a variety of reasons we are moving to a model were engineering will be responsible for feature releases *and* maintenance releases. Maintenance releases will be scheduled at regular intervals (approximately 3 months) and go through the full engineering development and QA process. The CS team will continue to generate D patches for specific customers reported problems. We will make every effort to incorporate all outstanding D patches into the next available maintenance release. (There will be a time window where this is not possible. D patches that are generated in the latter phase of maintenance release testing may be difficult to integrate at the 11th hour. We also don't want to delay the scheduled release of the maintenance release. The predictability is important.) Maintenance releases will be cumulative with respect to the bug fixes they contain. For example, X.2.3 should be a superset of X.2.2. We believe there is a good case to schedule these releases at regular intervals We appreciate the fact that upgrades are disruptive and time consuming. Predictable releases allow our customers to plan for these upgrades. It is also important that the release numbering system be clear and meaningful to customers. Our current D/P number is not always intuitive.

We are just beginning to move to this new model. There is likely to be some overlap between P releases and maintenance releases in the near term. I hope you can bear with us as we work through this transition.

I also agree with Paul regarding the rfe's. We need to do a better job of documenting the changes that go into these releases. Customers need accurate information about the content of these releases in order to make informed decisions in managing their filers. You should expect to see change here as well.

Thanks, Ken