Incremental deployment
From APIDesign
(→Update only needed pieces) |
|||
| Line 13: | Line 13: | ||
At the time of release 6.1 we realized that although we are offering various downloads (like [[Java]] edition, [[C]]/C++ edition, [[PHP]] edition, etc.), about 80% of people are downloading the full edition. Most of them never used all the technologies, but when the price is good (I mean zero) why not take it all? I knew why, because it would be bigger, slower and contain more bugs. However this was not what our customers realized, thus we had to do something with it. We invented [[netbeans:FitnessForever|Features on Demand]]! As a result people pay only for what they use even if they download everything. | At the time of release 6.1 we realized that although we are offering various downloads (like [[Java]] edition, [[C]]/C++ edition, [[PHP]] edition, etc.), about 80% of people are downloading the full edition. Most of them never used all the technologies, but when the price is good (I mean zero) why not take it all? I knew why, because it would be bigger, slower and contain more bugs. However this was not what our customers realized, thus we had to do something with it. We invented [[netbeans:FitnessForever|Features on Demand]]! As a result people pay only for what they use even if they download everything. | ||
| + | Two releases later we realized that [[netbeans:FitnessForever|Features on Demand!]] can be broken by updates of new modules. Such modules, often by default turned on, turn on also pieces of the [[netbeans:FitnessForever|Features on Demand!]] functionality effectively rendering it useless and some cases broken. To mitigate this problem we decided to updates only that part of functionality that is enabled. That is [[good]] solution, as the lowers the requirements on network bandwidth (only pieces that you really use are downloaded) and it also solves all previously known problems. | ||
| + | This was the state of the system at the time of [[NetBeans]] 7.0 release - [[modular]] and fully [[incremental deployment]] and enablement of all [[module]]s. | ||
| + | === An incompatible change === | ||
| + | === Easy fix === | ||
[[TBD]] | [[TBD]] | ||
| + | |||
| + | == Being compatible vs. Update it all! == | ||
| + | |||
[[Category:APIDesignPatterns:Evolution]] | [[Category:APIDesignPatterns:Evolution]] | ||
Revision as of 14:28, 7 August 2011
When talking about the need for BackwardCompatibility I often talk in context of distributed development. Without some sort of BackwardCompatibility you can't expect independent groups to develop on top of each other's libraries. This might imply, that BackwardCompatibility is only important when multiple (distributed) parties are involved. Paradoxically That would be a false conclusion. Here the following story!
Contents |
NetBeans 7.0.1 Bugfix Release
NetBeans 7.0 was released in May 2011. Since then we worked hard on subsequent bugfixing release, to be out in August 2011. Users of NetBeans bugfix releases have two options: either download whole bits from scratch or update their existing installation in place using plugin manager.
Traditionally we have problems upgrading (as that is not scenario tested during development) and bugs are discovered only by our quality department just at the time or release (maybe we could tight up our processes a bit). The release 7.0.1 was not an exception. There was a severe bug in the update scenario. But this one was very curious.
Update only needed pieces
The update process as used by NetBeans these days has hidden gotchas. First of all NetBeans has always been a modular system. However over time we had to mitigate various problems, so now we have a system that is not only modular, but also an example of incremental deployment.
At the time of release 6.1 we realized that although we are offering various downloads (like Java edition, C/C++ edition, PHP edition, etc.), about 80% of people are downloading the full edition. Most of them never used all the technologies, but when the price is good (I mean zero) why not take it all? I knew why, because it would be bigger, slower and contain more bugs. However this was not what our customers realized, thus we had to do something with it. We invented Features on Demand! As a result people pay only for what they use even if they download everything.
Two releases later we realized that Features on Demand! can be broken by updates of new modules. Such modules, often by default turned on, turn on also pieces of the Features on Demand! functionality effectively rendering it useless and some cases broken. To mitigate this problem we decided to updates only that part of functionality that is enabled. That is good solution, as the lowers the requirements on network bandwidth (only pieces that you really use are downloaded) and it also solves all previously known problems.
This was the state of the system at the time of NetBeans 7.0 release - modular and fully incremental deployment and enablement of all modules.
Follow
