On Sat, Apr 24, 2010 at 00:14, Tres Seaver tsea...@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
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 j...@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
Am 19.04.2010 um 22:21 schrieb Tres Seaver:
Log message for revision 45:
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
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
-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/
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
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,
On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver tsea...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver tsea...@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.
On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm j...@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/
On Fri, Apr 23, 2010 at 5:58 PM, Tres Seaver tsea...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm j...@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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
On Fri, Apr 23, 2010 at 5:58 PM, Tres Seaver tsea...@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.
-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:
14 matches
Mail list logo
