Murthy Chintalapati wrote: >> >> I think the more interesting question is >> whether or not during the course of successive >> Indiana releases there is a need to have more than one >> Apache 2.x release in play at a time. >> > > As customers take the stack into production use and as the Indiana makes it > easy to get the latest updates (potentially, with newer versions), wouldn't > having multiple versions provide customers a choice to stick with the stable > versions rather than being forced to upgrade what they have in production? > >
As I understand, Apache HTTPd community seems to follow a convention some where along the lines of 1. The product is released with major.minor.revision release values. With Apache HTTPd 2.2.4, major number is 2, minor is 2 and revision is 4. Even numbered release is considered to be 'stable'. 2. Even numbered 'revision' release (for example an update between 2.2.2 to 2.2.4) is mostly a bug fix stability release . This addresses any security vulnerabilities and other bug fixes. We need to encourage our customers to upgrade to this bug fix update. A typical release schedule based on past release history is about 6-10 months. Except for some very specific modules, there should not be incompatibilities between revision releases. 3. Even numbered 'minor' release is an update release where in new features show up and accordingly some level of incompatibility is allowed. For example, some module names have been changed between HTTPd 2.0 and 2.2. The basic rule of thumb is little porting effort should be needed to upgrade to a minor release. (For example, an upgrade to 2.0 to 2.2 requires simple (re)compilation of any custom developed or third party modules). A typical release schedule based on past release history is approximately around 5-6 years 4. A major release (like Apache 3) will involve some architectural changes besides some significant effort is needed to upgrade from Apache 2.x to Apache 3.x Whether we ship or add support to bundle multiple minor releases or a single apache 2 release (like the way how linux has successfully done so) is probably the big question. I guess, the answer to this question also depends on how much is the incompatibility between minor releases and how many customers very much want to have multiple minor releases. To wrap up this discussion, we probably need data on the following topics 1) What is the level of incompatibility between minor releases. Based on Apache 2.0 and Apache 2.2 http://httpd.apache.org/docs/2.2/upgrading.html It seems to me that the incompatibility between these minor releases is not very much a big deal and can be handled with a post install script. Do you guys agree ? Also, I am curious as to how Apache SMF scripts will work / look when we ship multiple minor releases or will we start shipping multiple SMF scripts to accommodate multiple minor releases as well. >> I'm fairly ignorant on the history of compatibility >> across different minor releases of Apache modulo what is documented in >> PSARC 2007/169 but I would suggest not introducing the additional >> hierarchy at this time. That said, I would love to hear what other >> vendors have done in this space and how realistic expectation is that >> users would tend to standardize on one particular 2.x version or one >> particular 1.x version. >> >> > My understanding is that there is typically just one version but I'll request > others to chime in here as well. > This message posted from opensolaris.org > > Most HTTPd distributors in Linux world has managed to successfully distribute only 1 apache 2 httpd module
