Hi,
in agreement with Jim Fulton and Brian Lloyd we decided to put the Zope 2.8
release on hold for now.
There are several open issues related to running Zope on Windows (building,
startup problems). Since
we need to have a stable source code release and a stable windows release
in sync, the ne
Martijn Faassen wrote:
yuppie wrote:
By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a
significant amount of work, due to all kinds of copyright headers
being different).
Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases
are ZPL 2.1, aren't they? Are there
Martijn Faassen wrote:
Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases
are ZPL 2.1, aren't they? Are there other things you did have to change?
Yes, some other things like taking out the monkey.py module, and some
documentation differences.
I want to get the headers in sy
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>
>>> Your unit test should exercise the whole API promised by an
>>> implementation anyway, so often an explicit interface check is redudant
>>> (of course, it can't hurt). verifyClass() per se isn't bad, it's in fact
>>> a useful indicator, b
Tres Seaver wrote:
Your unit test should exercise the whole API promised by an
implementation anyway, so often an explicit interface check is redudant
(of course, it can't hurt). verifyClass() per se isn't bad, it's in fact
a useful indicator, but having that it as a *sole* measure whether a
class
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> yuppie wrote:
>
4.) Making interfaces.zcml point to the new locations. [Five 1.0+]
5.) Adding unit tests that verify interfaces and implementations.
[Zope 2.8.0]
>>>
>>>
>>> IMHO that's yagni. We
yuppie wrote:
By the way, I've just merged in Five 1.0 into Zope 2.8 (which was a
significant amount of work, due to all kinds of copyright headers
being different).
Can't we use the same headers for Five 1.0 and Zope 2.8? Both releases
are ZPL 2.1, aren't they? Are there other things you did h
yuppie wrote:
Yes. I still don't see where the need for incompatability is. Maybe
I'm just blind. Can someone explain?
I no longer see a problem. If we make sure the Five interfaces and those
in the Zope tree are the same, there are no incompatibilities.
By the way, I've just merged in Five 1.0
yuppie wrote:
4.) Making interfaces.zcml point to the new locations. [Five 1.0+]
5.) Adding unit tests that verify interfaces and implementations.
[Zope 2.8.0]
IMHO that's yagni. We actually don't use interfaces that much for
verifying implementations anymore. I think their most common use in
Zo
yuppie wrote:
I don't think we need to break backward compatability. We would just
need to deprecate the Five.interfaces location.
Basically, the goals are:
* The solution needs to work with Zope 2.7
* Preferrably, the interface import spelling should be equal on both
systems (which means a mon
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Yes. I still don't see where the need for incompatability is. Maybe I'm
just blind. Can someone explain?
I no longer see a problem. If we make sure the Five interfaces and those
in the Zope tree are the same, there are no incompatibilities.
Philipp von Weitershausen wrote:
yuppie wrote:
Proposed Solution
=
[...]
3.) Doing the same for Zope 2.7 with monkey patching code. [Five 1.0+]
I assume here you mean patching in OFS.interfaces, webdav.interfaces etc...
Yes.
4.) Making interfaces.zcml point to the new locations. [F
Hi Philipp!
Philipp von Weitershausen wrote:
yuppie wrote:
Seriously, you should merge your r11978 to the Five-1.0 branch.0
Martijn was faster than I thought :(
I'll follow up to this in an other mail.
I don't think we need to break backward compatability. We would just
need to deprecate the Five.
Martijn Faassen wrote:
yuppie wrote:
[snip]
This way, all the work that remains for me is to merge in Five 1.0
into Zope 2.8.
My point is:
Doing that in a backward compatible way is impossible. So we have to
do it now or never.
That's true, but it's not that difficult to ask people to change the
yuppie wrote:
Current State
=
Five (now part of Zope 2.8) ships with one big interfaces.py file
that contains z3 interfaces for Zope 2 core classes. (There are also
some five specific interfaces in that file, but they are not subject
of this proposal.)
interfaces.zcml states that Zo
yuppie wrote:
[snip]
This way, all the work that remains for me is to merge in Five 1.0
into Zope 2.8.
My point is:
Doing that in a backward compatible way is impossible. So we have to do
it now or never.
That's true, but it's not that difficult to ask people to change their
ZCML files to point
yuppie wrote:
Proposed Solution
=
1.) Adding ZCML that bridges existing z2 interfaces into the
'interfaces' module of their package. [Zope 2.8.0]
+1
2.) Copying z3 interfaces from Five.interfaces to the 'interfaces'
module of the corresponding package. Marking those in Five as Zop
Hi!
Martijn Faassen wrote:
yuppie wrote:
[snip]
Current State
=
Five (now part of Zope 2.8) ships with one big interfaces.py file that
contains z3 interfaces for Zope 2 core classes. (There are also some
five specific interfaces in that file, but they are not subject of
this proposal
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
So you would have the Zope 2.8 interfaces exist in the Five.interfaces
module?
Well, no. Five.interfaces would stay as it is; it seems to be pretty accurate
for Zope 2.7 (especially with yuppie's fixes, which should be merged to the
Five-1.0
Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
> [snip]
> > Right. Here's what we could do:
> >
> > 1. Copy Five's interface definitions over to Zope 2.8 (mostly to
> > OFS.interfaces, I guess) where they are added as Zope 2 interfaces
> >
> > 2. Keep Five's (redudant) interface definiti
Hi!
Martijn Faassen wrote:
Andreas Jung wrote:
[snip]
-1. Such changes are not much acceptable *now*. 2.b2 will be released
this week and 2.8 final in about two weeks. Such changes should have
been proposed during alpha phase...but I am against such change in
this late release phase.
For Zope 2.8
Andreas Jung wrote:
[snip]
-1. Such changes are not much acceptable *now*. 2.b2 will be released
this week and 2.8 final in about two weeks. Such changes should have
been proposed during alpha phase...but I am against such change in
this late release phase.
That's a good point. Let's amend the pla
yuppie wrote:
[snip]
Current State
=
Five (now part of Zope 2.8) ships with one big interfaces.py file that
contains z3 interfaces for Zope 2 core classes. (There are also some
five specific interfaces in that file, but they are not subject of this
proposal.)
interfaces.zcml states
Philipp von Weitershausen wrote:
[snip]
Right. Here's what we could do:
1. Copy Five's interface definitions over to Zope 2.8 (mostly to
OFS.interfaces, I guess) where they are added as Zope 2 interfaces
2. Keep Five's (redudant) interface definitions. They can stay at their
status quo (status Z
--On Freitag, 6. Mai 2005 13:07 Uhr +0200 yuppie <[EMAIL PROTECTED]>
wrote:
Proposed Solution
=
1.) Adding ZCML that bridges existing z2 interfaces into the 'interfaces'
module of their package. [Zope 2.8.0]
2.) Copying z3 interfaces from Five.interfaces to the 'interfaces' modul
Hi again!
As discussed two days ago, I started working on integrating Five
interfaces closer into Zope 2.8. I believe I understand the problem
better now and like to propose a different way to resolve it:
Current State
=
Five (now part of Zope 2.8) ships with one big interfaces.py fi
26 matches
Mail list logo
