Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
Am 19.04.2010 um 22:21 schrieb Tres Seaver:
Log message for revision 111145: Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
Applications may need to fix up grants based on the old permissions.
fixes lp:566724
Changed: U zope.dublincore/trunk/CHANGES.txt U zope.dublincore/trunk/src/zope/dublincore/configure.zcml
-=- Modified: zope.dublincore/trunk/CHANGES.txt =============================================================== --- zope.dublincore/trunk/CHANGES.txt 2010-04-19 20:19:54 UTC (rev 111144) +++ zope.dublincore/trunk/CHANGES.txt 2010-04-19 20:21:52 UTC (rev 111145) @@ -5,6 +5,9 @@ 3.6.1 (2010-04-19) ==================
+- Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`. + Applications may need to fix up grants based on the old permissions.
Hi Tres, It's fine to rename these permissions, I like it. But this change is so big that it requires a new major version of this package: it requires changes in other packages, too, as you already said in your log message. Could you please: - unmerge these changes from the 3.6 branch and re-release a new 3.6.3 without the permission renaming, - do a new 3.7.0 release including the renaming and - depend on the 3.7 release in the packages where you updated ftesting.zcml to use the new permissions (zope.app.file and zope.app.container)? Thanks in advance. Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Michael, Tres I agree a new major version is required due to the new "feature" of having new permission names, but there is no reason to break compatibility with code using the old names. IIRC the <redefinePermission/> zcml-directive is there exactly to provide backwards compatibility when renaming permissions. Use like: <redefinePermission from = "<no longer defined permisison id>" to = "<existing permission id>" /> It is defined in zope.security:meta.zcml along with the <permission/> directive, so should be usable with any code that uses that. Best regards - Jacob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacob Holm wrote:
Hi Michael, Tres
I agree a new major version is required due to the new "feature" of having new permission names, but there is no reason to break compatibility with code using the old names.
IIRC the <redefinePermission/> zcml-directive is there exactly to provide backwards compatibility when renaming permissions. Use like:
<redefinePermission from = "<no longer defined permisison id>" to = "<existing permission id>" />
It is defined in zope.security:meta.zcml along with the <permission/> directive, so should be usable with any code that uses that.
Thanks for pointing out that directive, whose existence I had forgotten. Assuming we put the 'redefinePermssion' directives in place on the trunk, why shouldn't we leave the version number as is? I consider the rename a bugfix, not a feature, and if we make it backwared compatible, there is no reason to bump the major version. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvRnlwACgkQ+gerLs4ltQ5etgCg3UwAT0AGU+cu26+bLBbCRBp4 SG0AniEokjNlI9ReKVZu4Htu13wn2CQM =c0vh -----END PGP SIGNATURE-----
Hi Tres Tres Seaver wrote:
Assuming we put the 'redefinePermssion' directives in place on the trunk, why shouldn't we leave the version number as is? I consider the rename a bugfix, not a feature, and if we make it backwared compatible, there is no reason to bump the major version.
It's a (minor) public API change. IIRC we don't allow that in minor versions, even if it is just an addition. This goes back to the whole discussion of what kinds of version requirements to allow in setup.py. - Jacob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jacob Holm wrote:
Tres Seaver wrote:
Assuming we put the 'redefinePermssion' directives in place on the trunk, why shouldn't we leave the version number as is? I consider the rename a bugfix, not a feature, and if we make it backwared compatible, there is no reason to bump the major version.
It's a (minor) public API change. IIRC we don't allow that in minor versions, even if it is just an addition. This goes back to the whole discussion of what kinds of version requirements to allow in setup.py.
Such a policy would put us into an impossible situation: we would be unable to fix the bug in the API (which is that the permissions should have been renamed when the package was renamed) without making *multiple* unneeded releasess to the package. I play to release a 3.6.3 version which restores the old permission names and uses 'redefinePermisson' to map them onto the new ones, and then remove the BBB shim from the trunk, bumping the next version number to 3.7.0. Clients who still use the zope.app.dublincore permissions will therefore need to be updated before they can move to the next major version (which is why it is a major version). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvRq48ACgkQ+gerLs4ltQ4X4wCdHCnUKLWvvtjDkY16d7iP0avx YWsAn2bJW7bC+r0m/hxA1xcOhjv4eN1a =W1+3 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Jacob Holm wrote:
Tres Seaver wrote:
Assuming we put the 'redefinePermssion' directives in place on the trunk, why shouldn't we leave the version number as is? I consider the rename a bugfix, not a feature, and if we make it backwared compatible, there is no reason to bump the major version. It's a (minor) public API change. IIRC we don't allow that in minor versions, even if it is just an addition. This goes back to the whole discussion of what kinds of version requirements to allow in setup.py.
Such a policy would put us into an impossible situation: we would be unable to fix the bug in the API (which is that the permissions should have been renamed when the package was renamed) without making *multiple* unneeded releasess to the package.
I play to release a 3.6.3 version which restores the old permission names and uses 'redefinePermisson' to map them onto the new ones, and then remove the BBB shim from the trunk, bumping the next version number to 3.7.0. Clients who still use the zope.app.dublincore permissions will therefore need to be updated before they can move to the next major version (which is why it is a major version).
Done. The 3.6.3 release is up on PyPI: http://pypi.python.org/pypi/zope.dublincore/3.6.3 and the trunk is updated to indicate a forthcoming 3.7.0 release minus the BBB shims: http://svn.zope.org/zope.dublincore/trunk/?rev=111319&view=rev The ZTK test[-zope-app tests all pass with the trunk. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvR8DEACgkQ+gerLs4ltQ6TrQCfSmQxmTpsiR10tDA1qCLCLJUD B6YAoLG8clZpM+UxcABy45kU35DcnNI8 =mkuR -----END PGP SIGNATURE-----
On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver <tseaver@palladion.com> wrote:
Done. The 3.6.3 release is up on PyPI:
I guess I should get out more; just noticed this thread. Changing the stored permission names is a big deal. If a permission gets stored with zope.dublincore 3.6.3, then an instance running 3.6.(0|1) can't use it. This creates a problem for rolling restarts, where a permission stored by an instance with 3.6.3 may be accessed by an instance using 3.6.1 (or an even older version). Here's another possible approach: - Keep the zope.app.dublincore.* permissions in 3.6.x, with forward-compatibility adjustments in the ZCML, using <meta:redefinePermission from="zope.dublincore.change" to="zope.app.dublincode.change" /> - Change the permission names and add backward compatible ZCML in 3.7.x: <meta:redefinePermission from="zope.app.dublincode.change" to="zope.dublincore.change" />
and the trunk is updated to indicate a forthcoming 3.7.0 release minus the BBB shims:
If this even needs to be done, I'd like to see it be 4.0.0, because it's incompatible. This just doesn't seem valuable to me. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fred Drake wrote:
On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver <tseaver@palladion.com> wrote:
Done. The 3.6.3 release is up on PyPI:
I guess I should get out more; just noticed this thread.
Changing the stored permission names is a big deal. If a permission gets stored with zope.dublincore 3.6.3, then an instance running 3.6.(0|1) can't use it. This creates a problem for rolling restarts, where a permission stored by an instance with 3.6.3 may be accessed by an instance using 3.6.1 (or an even older version).
Here's another possible approach:
- Keep the zope.app.dublincore.* permissions in 3.6.x, with forward-compatibility adjustments in the ZCML, using
<meta:redefinePermission from="zope.dublincore.change" to="zope.app.dublincode.change" />
- Change the permission names and add backward compatible ZCML in 3.7.x:
<meta:redefinePermission from="zope.app.dublincode.change" to="zope.dublincore.change" />
and the trunk is updated to indicate a forthcoming 3.7.0 release minus the BBB shims:
If this even needs to be done, I'd like to see it be 4.0.0, because it's incompatible.
This just doesn't seem valuable to me.
I disagree, pretty strongly: making code forever responsible for bad old data is responsible for a lot of horrors in both Zope2 and Zope3 code bases. Releasing the packages separately allows the folks who need time to fix the data to have it, while still allowing development to continue without the burden. If you are running with a 3.6.x version of zope.dublincore, and you have persisted the permissions somehow, then you need to *evolve the data* before upgrading to 3.7.0. That is why 3.7.0 got the bump from 3.6.x. If you can't afford (yet) to evolve the data, then don't upgrade the package until you can. Running with 3.6.3 allows you to use either permission, as the zope.app.dublincore versions get upgraded in place to zope.dublincore equivalents. Or are you saying that the way 3.6.3 uses meta:redefinePermission won't work for persisted permissions? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvSF+oACgkQ+gerLs4ltQ7vVwCeMHD4uK8I60XpQ/ztWM9NJe/j tPEAn0g2jp23wm+WM9aPlRBlaHeQXNgv =i/iU -----END PGP SIGNATURE-----
On Fri, Apr 23, 2010 at 5:58 PM, Tres Seaver <tseaver@palladion.com> wrote: ...
I disagree, pretty strongly: making code forever responsible for bad old data is responsible for a lot of horrors in both Zope2 and Zope3 code bases. Releasing the packages separately allows the folks who need time to fix the data to have it, while still allowing development to continue without the burden.
If you are running with a 3.6.x version of zope.dublincore, and you have persisted the permissions somehow, then you need to *evolve the data* before upgrading to 3.7.0. That is why 3.7.0 got the bump from 3.6.x.
The bump to 3.7 would be due to a feature change. A backward-incompatible change would require a bump to 4.
If you can't afford (yet) to evolve the data, then don't upgrade the package until you can. Running with 3.6.3 allows you to use either permission, as the zope.app.dublincore versions get upgraded in place to zope.dublincore equivalents.
No. The declarations you give in 3.6.3 cause the new names to be mapped back to the old.
Or are you saying that the way 3.6.3 uses meta:redefinePermission won't work for persisted permissions?
It will. The redefinePermission change you propose for 3.7 won't, which makes it backward incompatible, which means it should be a 4.0 release. Jim -- Jim Fulton
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Fri, Apr 23, 2010 at 5:58 PM, Tres Seaver <tseaver@palladion.com> wrote: ...
I disagree, pretty strongly: making code forever responsible for bad old data is responsible for a lot of horrors in both Zope2 and Zope3 code bases. Releasing the packages separately allows the folks who need time to fix the data to have it, while still allowing development to continue without the burden.
If you are running with a 3.6.x version of zope.dublincore, and you have persisted the permissions somehow, then you need to *evolve the data* before upgrading to 3.7.0. That is why 3.7.0 got the bump from 3.6.x.
The bump to 3.7 would be due to a feature change. A backward-incompatible change would require a bump to 4.
If you can't afford (yet) to evolve the data, then don't upgrade the package until you can. Running with 3.6.3 allows you to use either permission, as the zope.app.dublincore versions get upgraded in place to zope.dublincore equivalents.
No. The declarations you give in 3.6.3 cause the new names to be mapped back to the old.
That was Fred, no me: my declarations mapped the old names forward to the new.
Or are you saying that the way 3.6.3 uses meta:redefinePermission won't work for persisted permissions?
It will. The redefinePermission change you propose for 3.7 won't, which makes it backward incompatible, which means it should be a 4.0 release.
I didn't propose a redefinePermission change for 3.7: I proposed to drop the (misnamed) permissions altogether from zope.dublincore. Why should zope.dublincore be carrying BBB-water for zope.app.dublincore? We have plenty of precedent for having the zope.app. version of the package stick around *purely* for BBB: let's do that in this case. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvSHt0ACgkQ+gerLs4ltQ4APQCgkC1Dc7+0ZANwfaTbE33a0WzS jJoAoKggDdu2TWZ9byhTWPSH/vsyJHh5 =RcJB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Why should zope.dublincore be carrying BBB-water for zope.app.dublincore? We have plenty of precedent for having the zope.app. version of the package stick around *purely* for BBB: let's do that in this case.
Even better: sites with persietent permissions no longer supplied by zope.dublincore can just add those permission declarations to their site.zcml: no software change involved, because ZCML is configuration / policy. The "default configurations" provided by packages like zope.dublincore are just that, default, starting points. "Reusable policy" is an oxymoron. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvSZrUACgkQ+gerLs4ltQ6RzACgnM2iONhqjBH3uIHhDQn46DIL k1AAnRXV9F+VjYyzBqTt34lxzDQ4OdNb =9JjA -----END PGP SIGNATURE-----
Am 23.04.2010 um 15:19 schrieb Tres Seaver: [...]
Thanks for pointing out that directive, whose existence I had forgotten. Assuming we put the 'redefinePermssion' directives in place on the trunk, why shouldn't we leave the version number as is? I consider the rename a bugfix, not a feature, and if we make it backwared compatible, there is no reason to bump the major version.
When it is fully backwards compatible I do not see a reason to bump the major version. Otherwise it is required according to the ZTK steering group decisions[1]. [1] ... http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html (sorry, there is no anchor for the list item I mean) Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm <jh@improva.dk> wrote:
Hi Michael, Tres
I agree a new major version is required due to the new "feature" of having new permission names, but there is no reason to break compatibility with code using the old names.
IIRC the <redefinePermission/> zcml-directive is there exactly to provide backwards compatibility when renaming permissions. Use like:
<redefinePermission from = "<no longer defined permisison id>" to = "<existing permission id>" />
It is defined in zope.security:meta.zcml along with the <permission/> directive, so should be usable with any code that uses that.
This only affects ZCML. It caused declarations for the old permission to be mapped to the new one. It doesn't affect stored permissions. Jim -- Jim Fulton
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm <jh@improva.dk> wrote:
Hi Michael, Tres
I agree a new major version is required due to the new "feature" of having new permission names, but there is no reason to break compatibility with code using the old names.
IIRC the <redefinePermission/> zcml-directive is there exactly to provide backwards compatibility when renaming permissions. Use like:
<redefinePermission from = "<no longer defined permisison id>" to = "<existing permission id>" />
It is defined in zope.security:meta.zcml along with the <permission/> directive, so should be usable with any code that uses that.
This only affects ZCML. It caused declarations for the old permission to be mapped to the new one. It doesn't affect stored permissions.
Maybe the short-term fix would be to add a shim package (reviving 'zope.app.dublincore', maybe) whose only job in life is to make those permissions loadable. Maybe the package ships with some code to help write the evolve script, or something. In the meanwhile, folks with persistent permissions should pin the version of zope.dublincore == 3.6.0. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvSG78ACgkQ+gerLs4ltQ4vsACfZA75jbybxkv+RZO4qW7R/6nO djoAoK1aFiODO5/zr2pl1DIIITgYHkrj =dEXv -----END PGP SIGNATURE-----
On Sat, Apr 24, 2010 at 00:14, Tres Seaver <tseaver@palladion.com> wrote:
Maybe the short-term fix would be to add a shim package (reviving 'zope.app.dublincore', maybe) whose only job in life is to make those permissions loadable. Maybe the package ships with some code to help write the evolve script, or something.
This seems to be the correct way to me, if possible. (How many letters I used to say +1. Why did I do that? It might be some sort of existential crisis. Or it's just early in the morning and I'm still half asleep. ) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
On Fri, Apr 23, 2010 at 06:14:23PM -0400, Tres Seaver wrote:
Jim Fulton wrote:
On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm <jh@improva.dk> wrote:
Hi Michael, Tres
I agree a new major version is required due to the new "feature" of having new permission names, but there is no reason to break compatibility with code using the old names.
IIRC the <redefinePermission/> zcml-directive is there exactly to provide backwards compatibility when renaming permissions. Use like:
<redefinePermission from = "<no longer defined permisison id>" to = "<existing permission id>" />
It is defined in zope.security:meta.zcml along with the <permission/> directive, so should be usable with any code that uses that.
This only affects ZCML. It caused declarations for the old permission to be mapped to the new one. It doesn't affect stored permissions.
Maybe the short-term fix would be to add a shim package (reviving 'zope.app.dublincore', maybe) whose only job in life is to make those permissions loadable. Maybe the package ships with some code to help write the evolve script, or something.
In the meanwhile, folks with persistent permissions should pin the version of zope.dublincore == 3.6.0.
*Please* mention this in the changelog in big fat letters. People who upgrade, say, from the 3.4 KGS to BlueBream 1.0 won't necessarily have read every zope-dev discussion for the last three years. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
participants (7)
-
Fred Drake -
Jacob Holm -
Jim Fulton -
Lennart Regebro -
Marius Gedminas -
Michael Howitz -
Tres Seaver