Robert Story wrote: > On Fri, 18 Aug 2006 14:41:32 +0100 Dave wrote: > DS> I must admit that I'm drawn to Wes' original position - a patches > DS> branch shouldn't include incompatible changes, so ought to continue > DS> with the same library number throughout. > > I agree too. The hardline position would be that a bug that could only be > fixed in such a manner that binary compatibility simply wouldn't be fixed, and > we would simply tell everyone to upgrade. And hope that the fix isn't for a > security issue, because you know it's not easy to get everyone to upgrade. > > DS> [...] But just allowing one single library change within a > DS> given patches branch feels extremely shortsighted. How would we > DS> decide when to allow that one change? And what we would do when we > DS> wanted to make another (possibly more vital) change in the same line. > > If you s/wanted/needed/, then that's exactly my point. The idea isn't to open > up old lines for whimsical changes, but for real bugfixes that break binary > compatibility. A good example would be having to change a structure member > from an int to size_t, which would be binary incompatible on a 64bit system.
After all we're looking for a compromise here. The hardline position calls for no incompatible changes within a branch, so any gap would just be a waste. The cautious position is worried about not having enough gap to compensate for yet another structure change. So let's find a compromise for a realistic position here. How many releases are we even doing in a branch? We've EOLed 5.1.x after 5.1.4, so even if we would have introduced incomatible changes for *each* release in that branch, we'd have only needed a gap of 5. My vote is still for a gap of 1, reserved for emergencies (major/security issues). There's an easy way to make this a success: let's go through the compiler warnings on a 64-bit system and address them before releasing a new major release (like 5.4). I consider our time much better spent with this than to continue arguing on how to compensate for *not* doing it. +Thomas -- Thomas Anders (thomas.anders at blue-cable.de) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
