Danek Duvall wrote: > > And I understand why those are that way. But I'm not asking about why it's > done in general (like you said, this isn't the apache case), but about this > particular case. Does lighthttpd need to be treated the same way? Is > there a rich community of end-user plugins for lighttpd the way there is > for php and apache? Is there binary incompatibility between releases that > will cause end-user plugins to break when we upgrade? Are there other > things that would go wrong? > > I'm not saying there isn't, but I don't know -- I'm not terribly familiar > with lighttpd. But I strongly get the sense that some teams are versioning > the installations because they don't actually want to do the work to find > out whether a) there actually are incompatibilities between the releases > they might conceivably ship, b) those incompatibilities are relevant to > customers and not something the distro can smooth over the transition, and > c) customers really will want more than one version at a time, rather than > making a jump. >
We can't really work on the off chance that releases of Lighttpd will be compatible, this would actually need commitment from the Lighttpd community, some of which they are able to give us (still talking with them about this). Not knowing what incompatibilities might exist in future releases makes it difficult to understand what would be possible when it came to having the "distro smooth over the transition". As for c) we are trying to have customers come to OpenSolaris on the basis that Lighttpd is available and well integrated, we don't have the data point as to whether OpenSolaris customers will want to have more than one version currently. I can see the point in the argument that says "well, let's integrate Lighttpd without versioning and if necessary version at some point in the future". But if we integrate Lighttpd as 'lighttpd' (as uncommitted) then we are committing to support that version until the next minor release of Solaris, we would not be able to just move to a new but incompatible release through a solaris patch or update release. We would have to create a new package: lighttpd15 or lighttpd2 in order to make the new release available to end users. Of course this all comes back to "what do you mean by incompatible" and I would say that it means that when a user installs an upgrade release of Solaris or applies a Solaris patch, some functionality of Lighttpd is either broken or missing. This could be as simple as a syntax change in the config file, it may even be that some module that they relied on is removed in the new release (probably would have been deprecated first, but even if the user knew this it would still come as a surprise to find it gone). This is why versioning was felt to be necessary for this case, not because of any specific evidence of incompatibilities but because there are no guarantees that there won't be incompatibilities. The Lighttpd community have been great, we have been talking to them, although it's difficult to get all of them in one place at the same time. Jan who's replied on this thread has been talking to us about the compatibility of Lighttpd between releases and what the community could commit to. Based on this it's possible that we could delay versioning Lighttpd, but it really would only be a delay, because at some point we will hit incompatibilities that will require us to version Lighttpd, almost definitely with the next non-micro release. Thanks Amanda > Perhaps that analysis actually has been done, but I don't see any evidence > of it. > > >> They do it presumably for the same reasons several of the OpenSolaris >> project teams have felt the need, which is to provide stability within a >> given major release family while at the same time making the >> newer-generation apps available. >> > > I'd like to take the "presumably" out of that. If there's a real need for > the versioning, let's hear it. If there isn't, let's not do it. > > >>> Yup. I don't agree with the way Apache has been versioned, either, though >>> I understand why we delivered both 1.3 and 2.x for a while. Why we haven't >>> yet gotten rid of 1.3, or why we now ship two versions of 2.x is completely >>> beyond me. I think it's nuts. >>> >> There's only one apache22. apache1 is best thought of as a different >> product just sharing the same first name, still with its user base. >> > > I get that. But I do have SUNWapch2u and SUNWapch22u on my build 83 system > (the first delivering 2.2.3, the second 2.2.6). Perhaps the appropriate > pkghistory files haven't been delivered, so the older copy isn't being > removed? > > >> Anyway, this is not the apache case. >> > > I only brought it up because I didn't think a good decision had been made > there. Though the binary compatibility argument makes sense to me, as > long as there are enough customers for each version range with isolated > compatibility to make them worth supporting. That doesn't mean I don't > still think it's nuts that people are still using 1.3 how many years after > 2.x came out? > > >> Some of the OpenSolaris components have finer-grained versioning than in >> Linux, because the Solaris lifecycle and stability expectations are >> different. Uncommitted still means stable until the next minor release, >> which is a very long time. >> > > Unfortunately, the release taxonomy is being shredded at the moment. We > used to be able to say that until the in-development release (Nevada at the > moment) actually shipped, you could do pretty much anything you wanted, > including making incompatible change, and you were only locked in at > release. But no one's really sure what that means when you throw SXDE or > Indiana into the mix. > > Danek >
