Gustaf Neumann wrote: > Forward-looking does certainly not mean that we do not want > to keep compatibility (we have all large code bases using > naviserver) but i would certainly hate to see e.g. the > useless $conn argument to be re-introduced in naviserver > just because some 10+ year old code expects it. > > The general rule of change should be > major-versions-are-allowed-to-break-backward-compatibility > and > minor-versions-should-keep-backward-compatbility > where we are talking about intra-naviserver compatibility.
This is pretty standard and sensible for a project supported by volunteers. However, what I'd like to see - when reasonable - is an option for backwards compatibility, either by setting a config flag or loading a compatibility module, as nsshare appears to be shaping up into. Adding in a version of ns_register_filter that passes aolserver-style args would not be a stretch. This I think could give the best of both worlds - improvements in functionality without alienation of user base. -J ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
