James Carlson wrote: > Darren J Moffat writes: >>> I would prefer to leave this as a straight 2.2.4 for 2.0 >>> replacement and open a subsequent case for the EOL/EOF of Apache 1.x. >> That is fine with me. > > With the clarification that this case seeks Minor release binding, and > the fact that 2.0 is in S10, what's the upgrade story for users going > from S10 to S10+1? > > Since we're reusing the same path, it sounds like applications may > just break after upgrading, and there's no way to do a transition. Is > that correct?
Yes this is correct. The current proposal *overwrites* the existing /usr/apache2 binaries with binary incompatible bits [corresponding directories in /etc and var will not be overwritten destructively]. The result is that *existing* customer modules will break. There is no transition path. > Does this case also cover upgrading subversion from libapr-0.9 to > libapr-1.2? If not, then is delivery of this project dependent on a > future case that does this upgrade? We've already approved subversion > in Solaris (PSARC 2006/563), so I think this project is incomplete if > it doesn't address the compatibility issue. Subversion should link against the new apr-1.2 bits, not against the old apr-0.9 bits. > The only answer I've seen so far is from Stefan Teleman saying that > subversion would have to go through a "full regression test" -- > whatever that means -- That means that it should run all the tests provided with Subversion and ascertain that all of them pass. > but no indication of who would actually do the > work to switch this over, and whether that delivery is part of this > project, or if the existing SUNWsvn just stops working. In the currently proposed scenario SUNWsvn will break. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
