-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been thinking about something for a while, but it came up again just now - in fact it seems to come up fairly often. The word "stable", with ezpublish, doesn't seem to mean what I think it means.
We run ezpublish from subversion, to facilitate easy upgrades to multiple ez sites we host. We use the "stable" branches, currently stable/3.10, as my understanding is this most closely tracks the released (packaged) versions. I thought that the stable branch was supposed to be the latest release, plus any stable bug fixes that have been added since the release was made, however for that to be the case I think the policy of how bugs fixes are added to stable doesn't work quite right. I'm talking abstractly, let me give an example... Revision 20820 improved the updateniceurls.php because it was taking too long to run on sites with a large number of nodes. That was great... I had one 3.9 -> 3.10 upgrade take 5 hours, and the need for improvement was clear. But there was a small bug, fixed in 20843. Unfortunately, I updated our svn codebase in between those two revisions, and forgot to update again before my colleague tried to migrate a site from 3.9 to 3.10 earlier today. The result was that no entries were made in the parent column in the ezurlalias_ml table, and after the upgrade the url for every node in the site appeared to be at the top level, i.e. instead of: example.com/1 example.com/1/2 example.com/x/y/3 we got: example.com/1 example.com/2 example.com/3 Of course, it didn't take very long to look at the database, realise the problem, upgrade svn, re-run the updateniceurls.php script with - --import, and clear caches, fixing everything, but that made me wonder... Why was that "fix" to the speed of the updateniceurls.php script applied to stable immediately? If any comprehensive testing was done on the functions of that script, it should have revealed straight away that it wasn't working properly... it wasn't really a "stable" change, at least the way I understand the word stable. Please don't take this the wrong way, I'm not trying to complain about that bug - it's merely a small case in point. I'm genuinely curious why this policy works as it does - changes are applied to trunk *and* stable simultaneously without letting non-trivial bug fixes that may contain errors (and in fact make things worse) mature in trunk before migrating to stable. Possibly there could be another "testing" level in svn before changes migrate to stable, or maybe changes could be flagged somehow so that non-trivial changes have a cooling-off period in trunk before being applied to stable. I'm no svn guru, so I don't know how that could work, but it seems to be a systemic problem with how ez svn works, so I'm curious if you have considered these issues, and any possible solutions. Thanks Matthew - -- Matthew Carroll http://carroll.org.uk GPG Key: http://carroll.org.uk/matthew_carroll.asc gpg --keyserver pgp.mit.edu --recv-keys C3388825 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHYDyrAK4c1sM4iCURAtwKAKCxOzp9WttCt64TQTWcGr04zx3l+gCg6fC5 fmB8dmjzNEbije72eAA0cOo= =pHXa -----END PGP SIGNATURE----- -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
