On Wed, Sep 05, 2007 at 02:50:00PM -0700, Sriram Natarajan wrote: > 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'. > You misunderstand it partially. The even number ~ stable only applies to "minor" - 2.0.X and 2.2.X are stable branches and since about 2.0.50, they have also run with an ABI compat requirement inside a stable branch (such that any module that runs on 2.2.X should be fine for any value of X - while it isn't guaranteed to run on 2.0.X). Any confusion you may have had about 2.2.uneven being unstable could have come from the policy of tagging for release and if it proves to need further changes, then a new tag will be created for testing before deciding to release. So some tags will never be released (as has recently happened for 2.2.5 and 2.0.60 that will never go out as releases).
> 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. > See above, you're wrong again. > 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 > See above - still not correct. And also don't assume too much about timing of release cycles, there just isn't any way to be sure. > 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 > Most likely correct, but only time will tell. > 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. > Given the differences between 2.2 and 2.0, I think both need to be available for quite some time (as some vendors of proprietary modules still haven't made the jump). > 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 ? > Absolutely - with the ABI compat rule, there will be no incompatibilities. > 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. > Picking the version by setting a property seems like a simple way or possibly as part of the FMRI. vh Mads Toftum -- http://soulfood.dk
