whit wrote:
I remember some discussion of this in the past.
Transitionally, it would be helpful to be able to register local
utilities to a tool name, and then have getToolByName spit out a
deprecation warning and return an appropriate object.
Why a deprecation warning and not just do it?
The following supporters have open issues assigned to them in this collector
(http://www.zope.org/Collectors/CMF).
Assigned and Open
jens
- Discussion replies removal,
[Accepted] http://www.zope.org/Collectors/CMF/391
- 'CMF Default Workflow [Revision 2]' Extension broken,
Hi Florent!
Florent Guillaume wrote:
Florent Guillaume wrote:
I recently introduced the fact that in extension profiles list
properties aren't purged by default.
But really this introduces problems, as if you simply import an
extension profile twice you'll get all you lists doubled.
So I
Hi Jens!
Jens Vagelpohl wrote:
On 16 Jan 2006, at 18:28, Jens Vagelpohl wrote:
On 15 Jan 2006, at 18:38, Jens Vagelpohl wrote:
Before cutting the CMF 2.0 alpha GenericSetup should move out of the
CMF repository. I'm volunteering to do that. Is there anything or
anyone I need to wait on
On 17 Jan 2006, at 10:44, yuppie wrote:
Work finished, please check out GenericSetup from here now:
svn+ssh://svn.zope.org/repos/main/GenericSetup/trunk
The original proposal also proposed to include it in the CMF via a
svn:external link, see
I agree that Five development should happen in Five 1.4. This version
would then be the basis for Five in Zope 2.10. Increasing Zope 3
compatibility there is good and high priority. Doing so in Five 1.2 is
quite low priroty, since that runs on an old version of Zope 3, on
which new development
On 17 Jan 2006, at 10:28, yuppie wrote:
Florent Guillaume wrote:
Florent Guillaume wrote:
I recently introduced the fact that in extension profiles list
properties aren't purged by default.
But really this introduces problems, as if you simply import an
extension profile twice you'll get
On 1/17/06, Raphael Ritz [EMAIL PROTECTED] wrote:
It was the promise that 'getToolByName' would always just do
the right thing (TM) so that add-on developers would not have
to worry. So why deprecating that now?
Because that promise has been completely revoked, since add-ons
developed for old
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
On 17 Jan 2006, at 10:44, yuppie wrote:
Work finished, please check out GenericSetup from here now:
svn+ssh://svn.zope.org/repos/main/GenericSetup/trunk
The original proposal also proposed to include it in the CMF via a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
On 17 Jan 2006, at 15:39, Tres Seaver wrote:
What do people think, do we want a svn:external or do we want to just
mention it as a requirement in the docs (such as README, INSTALL,
DEPENDENCIES)?
I don't think the
On 17 Jan 2006, at 16:13, Tres Seaver wrote:
I don't think the burden of maintaining 'svn:external' is worse
than the
burden of maintaining the correct version ID in DEPENDENCIES.txt. I
*want* to distribute GenericSetup with the CMF tarball, in fact,
which
makes 'svn:external' seem the
howdy lennart!
Right, any tool that now exists must directly map unto a local
utility, and that local utility must also have the same API.
If we in CMF 2.0 feel that most tools should be made into utilities,
we could register the utilities with a name, and use the old tool
name. getToolByName
Hi all,
I will cut the CMF 2.0 alpha this coming Sunday, no matter what. I'll
do as much as I can myself as far as cleanup goes beforehand, but in
order to get it out I'm no longer waiting for others' tasks.
The alpha is *not* the branching point for a 2.0 branch, that happens
when the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
On 17 Jan 2006, at 16:13, Tres Seaver wrote:
I don't think the burden of maintaining 'svn:external' is worse
than the
burden of maintaining the correct version ID in DEPENDENCIES.txt. I
*want* to distribute
On 17 Jan 2006, at 15:39, Tres Seaver wrote:
What do people think, do we want a svn:external or do we want to just
mention it as a requirement in the docs (such as README, INSTALL,
DEPENDENCIES)?
I don't think the burden of maintaining 'svn:external' is worse
than the
burden of maintaining
Jens Vagelpohl wrote:
OK, all done now.
jens
Hmm... I think you forgot to do the svn:externals for CMF 1.6 branch
too? (was GenericSetup removed from there as well?)
- Rocky
--
Rocky Burt
ServerZen Software -- http://www.serverzen.com
ServerZen Hosting -- http://www.serverzenhosting.net
On 17 Jan 2006, at 20:47, Rocky Burt wrote:
Jens Vagelpohl wrote:
OK, all done now.
jens
Hmm... I think you forgot to do the svn:externals for CMF 1.6 branch
too? (was GenericSetup removed from there as well?)
No I did not.
snip
Log message for revision 41349:
- stitching
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Florent,
I'd like to get the CMF-trunk clean of Deprecation warnings, at least
when running unit tests or starting up Zope, and those emitted by
OFS.subscribers are the remaining ones I know about.
How do you mean for objects to handle the case
On Mon, 16 Jan 2006 11:41:23 -, Martijn Faassen [EMAIL PROTECTED]
wrote:
How urgent is it that all of this works with Zope 2.8? I guess it's
urgent if you want to sell it to the Plone community, which will only
switch to Zope 2.9 or beyond by next year or so, I expect. How much more
On Mon, 16 Jan 2006 15:50:44 -, whit [EMAIL PROTECTED] wrote:
In actuality, the number of products that anyone depends on will not be
using this in 2.8, but making it available to 2.8 will give people an
opportunity to use this and familiarize themselves. for example, Plone
will be on
Martin Aspeli wrote:
The broader point is we wouldn't really need it yet - we don't have any
code that actually uses these new features, and plenty of code that may
be broken by changes in CMF 2. All in good time - of course, if you
want to help work on CMF 2.0 compatability for the 2.5
On Mon, 16 Jan 2006 14:37:41 -, Rocky Burt [EMAIL PROTECTED] wrote:
I think there are two reasons Plone 2.5 is targetting CMF 1.6 (instead
of just going to CMF 2.0)
1) the risk that CMF 2.0 wouldn't be ready when plone -- and I'm
pretty sure the 6 month release rule has already been
Alexander Limi wrote:
From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over
2.8. Below you are suggesting that Plone 2.5 should do the same with
Zope 2.8 (favouring it over 2.9). I don't understand why that should be.
If one version has to be favoured at all, it should be
23 matches
Mail list logo
