Last modified: 2012-07-03 16:32:45 UTC
some changes in 1.20wmf6 are done on export-0.7.xsd, which now needs a purge/update to get the new changes visible. Maybe the deployment can have a automatic way to do this. Thanks.
(In reply to comment #0) > some changes in 1.20wmf6 are done on export-0.7.xsd, which now needs a > purge/update to get the new changes visible. > > Maybe the deployment can have a automatic way to do this. > > Thanks. It's probably not worth it, for the relative infrequency. Maybe we should symlink the xsds back to the /h/w/c/php directory to remove the need to actually update them. Then it's just a squid purge to clear the caches for them
But linking only the xsds will only work, when there are updates for the xsd. But when a new version is added, that does not work. Needs a "mask symlink" (I do not know, if that works) like export-*.xsd or *.xsd or creating an own folder "export" inside "docs", than the export-demo.xml can also get public. Running a purge script for the squid while the "big deployment" sounds not hard to do.
(In reply to comment #2) > But linking only the xsds will only work, when there are updates for the xsd. > But when a new version is added, that does not work. Needs a "mask symlink" (I > do not know, if that works) like export-*.xsd or *.xsd or creating an own > folder "export" inside "docs", than the export-demo.xml can also get public. > > Running a purge script for the squid while the "big deployment" sounds not hard > to do. We have a script to do precisely that shipped with MediaWiki The point is so these don't need updating every 5 minutes due to development changes through a release cycle
Done
