On 10/18/10 21:16 PM, Michael Howitz wrote:
> Am 18.10.2010 um 11:02 schrieb Jan-Wijbrand Kolman:
>> I propose to release this as 1.5.0, which would be a major version
>> release that would indicate: "Watch out, potentially backwards
>> incompatible changes ahead!".
>>
>> Right?
>
> +1 looks nice.
Am 18.10.2010 um 11:02 schrieb Jan-Wijbrand Kolman:
> Hi Michael and Marius,
>
> Thanks for the feedback and suggestions! This is what I did:
>
> On 10/13/10 15:37 , Michael Howitz wrote:
>> Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
>>> Then there's no real need for a browser extra, as
Hi Michael and Marius,
Thanks for the feedback and suggestions! This is what I did:
On 10/13/10 15:37 , Michael Howitz wrote:
> Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
>> Then there's no real need for a browser extra, as the browser
>> subpackage does not really have any code (only re
Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
> On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
>> Good idea. This would improve the testing situation. That would
>> definitely help the Grok Toolkit, as it could then run the "normal"
>> tests in the context of the toolkit, without pulling in
On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote:
> On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
> > Good idea. This would improve the testing situation. That would
> > definitely help the Grok Toolkit, as it could then run the "normal"
> > tests in the context of the toolkit,
On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
> Good idea. This would improve the testing situation. That would
> definitely help the Grok Toolkit, as it could then run the "normal"
> tests in the context of the toolkit, without pulling in the dependencies
> of the browser tests.
Ah, no it wouldn
On 10/13/10 13:16 , Michael Howitz wrote:
> Am 13.10.2010 um 10:02 schrieb Jan-Wijbrand Kolman:
>> If I would be pedantic here I'd say there is no such thing as
>> renaming a permission. When the old name is gone, it is gone.
>> There's no mechanism similar to the BBB imports for the permission
>>
Am 13.10.2010 um 10:02 schrieb Jan-Wijbrand Kolman:
> On 10/6/10 08:08 , Michael Howitz wrote:
>> Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
>>> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended
>>> on a permission name that has been removed from zope.dublincore).
>>
>>
On 10/6/10 08:08 , Michael Howitz wrote:
> Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
>> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended
>> on a permission name that has been removed from zope.dublincore).
>
> Actually the permission has been renamed (from zope.app.dubl
Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
> Hi,
>
> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a
> permission name that has been removed from zope.dublincore).
Actually the permission has been renamed (from zope.app.dublincore to
zope.dublincore) to get ri
2010/10/5, Jan-Wijbrand Kolman :
> Hi,
>
> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a
> permission name that has been removed from zope.dublincore). This made
> me realize that zc.catalog contains ZMI code in the browser subpackage.
>
> Are people still using this ZMI
I would like the ZMI views and zope.app dependencies be removed as
well. I think I remember even some tests fail with ztk1.0?
2010/10/5, Jan-Wijbrand Kolman :
> Hi,
>
> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a
> permission name that has been removed from zope.dublin
Hi,
Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a
permission name that has been removed from zope.dublincore). This made
me realize that zc.catalog contains ZMI code in the browser subpackage.
Are people still using this ZMI code from zc.catalog? Would it be an
idea
13 matches
Mail list logo
