Stefan Teleman wrote: > > >> This does assume 2.2 interfaces are Uncommitted. They could be made >> Volatile in which case the above issue is not an issue as far as >> stability contracts (of course it still results in an annoyed user). >> But there has been reclutance in using Volatile. >> > > This was precisely the assumption made when Apache 2.0.x was first integrated > in > Solaris: that Minor/Micro Apache releases will stay binary compatible. > > Turned out not to be the case. > > With respect to open source components, we can never really claim binary compatibility as we don't control what goes into the release. Now the question is - does the customer really want that level of compatibility that we are used to provide in Solaris world ? Is there any customer data to suggest us going this route ?
My point of argument / concern is when other HTTPd distributors have successfully managed with shipping a single HTTPd distribution, how we are different ? If the same file layout is going to be integrated into Solaris 10 Update 5, yes I agree that we need to be very conservative. But, right now , our focus being Indiana and with its release model, does it really warrant to ship multiple minor releases. If customers really worry about binary incompatibility with minor releases of Apache HTTPd , then why Ubuntu or other distributions not following this convention ? Without any customer data to back up this claim one way or the other, my suggestion is that we take the simplest approach with clearly mentioning that these binaries are not meant to be compatible between releases. Now, again, as I mentioned earlier, if there is enough consensus in the community to ship multiple releases, then let us do it. Looks like, at this point, that is where we are heading. thanks sriram
