| > These are the release notes for 2.7 | > http://mirrors.dotsrc.org/squid/squid-2/STABLE/squid-2.7.STABLE1-RELEASENOTES.html | > | > there were additions and delitions of directives from squid.conf. Do | > they count as modifications requiring ARC? (they are public interface I | > suppose.) | | If it were a Sun product every new option would certainly need to be | discussed in detail in the ARC case. | | Being a third party application, if all changes are simple, I'd be | satisfied ARC-wise with just an automatic case which lists the | upstream public feature changes from the release notes.
I will do this. | There's one potential catch though, I see a few removed directives | (and some changed directives) in the release notes. What is the impact | on compatibility for users upgrading? | | Is it a seamless experience? Or do some features stop working? Does it | error out on missing directives? Do users need to do anything beyond | simply "pkg image-update" when upgrading? Any migration issues? To quote a sample, http://www.squid-cache.org/Doc/config/min_icp_poll_cnt/ "Heavy voodoo here. I can't even believe you are reading this. Are you crazy? Don't even think about adjusting these unless you understand the algorithms in comm_select.c first!" Starting the squid with these options enabled produces a line in the configuration file like "2009/02/12 19:09:19| parseConfigFile: squid.conf:709 unrecognized: 'incoming_icp_average'" And squid continues to work. Also, these directives were tuning values for algorithms rather than enabling functionalities, so they are not breaking changes. | In the worst case, if there are unresolvable incompatibilities you may | need to ship multiple versions as done by Apache/MySQL and others. | Hopefully that doesn't turn out to be necessary... This may soon be necessary for adding squid 3.0, do you think we should start keeping versions for squid 2.x too? in view of the eventual need?
