On Fri, 2007-04-20 at 12:57 -0400, Konstantin Ryabitsev wrote: > Come on, this is PHP we're talking about. Code breakage going from > php-5.1.6 to php-5.2 is not any more likely to occur than going from > php-5.1.5 to php-5.1.6, if the history of the project has anything to > tell us on that matter.
Right, but RHEL is no more likely to move from 5.1.5 to 5.1.6 than they are to 5.2.x. If you look at the history of RHEL from 2.1 forward, I don't think the PHP version has ever changed from initial release. Heck, effectively, that's what I pay them for, to keep the version stable, but still supported. > In fact, the upstream specifically says: "Most > improvements in PHP 5.2.x have no impact on existing code." > (http://ca3.php.net/UPDATE_5_2.txt) Right, it's that "most" part that's the problem. Another way to read that is "Some improvements in PHP 5.2.x have impact on existing code." For those of us with strict change policies and tons of servers and applications to support, "some" could huge. Heck, since you never know which application it will be, even affecting any code is an issue. Of course, it's also possible that a backport could break code, but generally far more likely, and at that point I may have to accept that security is more critical than not breaking code. > In fact, the upstream is considering 5.2 as the continuation of 5.1, > and the decision to increment the version was due to additional > functionality. Additional functionality breaks things. Any Windows admin will tell you the frustration of service packs which "add functionality" and the nightmare this can cause. > > *especially* given that it's unlikely upgrading to 5.2 would be *required* > > for security anyway. > > That's not true. There will be no future releases in the php-5.1 line, > so all fixes will have to be backported from 5.2. As the projects > diverge more and more, that will become increasingly difficult. That's true, but Redhat has to deal with that anyway. Even if they move to 5.2 in seven years the PHP project is likely to be on PHP 7.3.14 or something so that doesn't really matter. For example, RHEL2.1 is still supported, and comes with PHP 4.1.2. Updates for this package just came out in the last week or so. > I'm not saying that RH should upgrade to 5.2 -- it's their decision > whether they want to keep the 5.1 line and apply backpatches to it. > However, I'm just wondering out loud whether it would make more sense > to go up to 5.2, since RHEL5 *just* came out and there are going to be > a lot fewer sites relying on php-5.1 than there will be a year from > now. Actually, even with all that I said above, I could see the advantages to doing so, I just don't think it's going to happen because it doesn't follow the model of keeping versions consistent, even if it is early in the release cycle. Later, Tom _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
