Hi Chris!
Chris McDonough wrote:
On Jun 14, 2006, at 1:00 PM, yuppie wrote:
It's not that simple. registerClass has an optional 'legacy' argument
that does something quite similar. It just monkey patches
ObjectManager instead of Folder. So at least for some use cases
registerClass *will* hel
On 14 Jun 2006, at 22:06, Dieter Maurer wrote:
Florent Guillaume wrote at 2006-6-13 22:13 +0200:
Yes but the deprecation has been there for a while, and the third
party product developers have been ignoring the warning. Their loss.
Interestingly, it is usually not the loss for the third party
Chris Withers wrote at 2006-6-14 07:32 +0100:
> ...
>Would be interested to know what other people think...
I like time based releases but I hate deprecations
for "cosmetic annoyances" (term stolen from Andreas).
I have the feeling that most deprecations so far
have been for "cosmetics" only.
Florent Guillaume wrote at 2006-6-13 22:13 +0200:
> ...
>Yes but the deprecation has been there for a while, and the third
>party product developers have been ignoring the warning. Their loss.
Interestingly, it is usually not the loss for the third party product
developers (as they usually gain
Hi yuppie...
On Jun 14, 2006, at 1:00 PM, yuppie wrote:
Hi Chris!
Chris McDonough wrote:
On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote:
Reading the sources I had the impression that the fact there was
no warning for the deprecated feature was a bug and I did
consider my change a bugfi
Paul Winkler wrote:
On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote:
I think that's the sanest policy. So it's OK if "bullshit" gets
called on people putting deprecation warnings into any .1, .2, etc
through .9 releases, then? This seems like the only thing that can
work.
On Jun 14, 2006, at 1:09 PM, Lennart Regebro wrote:
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
There are problems with the deprecation period, but only for
__ac_permissions__ and meta_types assuming we choose not to deprecate
'methods'.
The problem in this case being that we didn
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
There are problems with the deprecation period, but only for
__ac_permissions__ and meta_types assuming we choose not to deprecate
'methods'.
The problem in this case being that we didn't use to issue deprecation
warnings. ;)
In any case,
Hi Chris!
Chris McDonough wrote:
On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote:
Reading the sources I had the impression
that the fact there was no warning for the deprecated feature was a bug
and I did consider my change a bugfix. Without warning it was already
deprecated for many years.
On Jun 14, 2006, at 12:32 PM, Lennart Regebro wrote:
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
That is the case for meta_types and __ac_permissions__ but I think
you
mistook the fact that "methods" followed a comment that said "handle
old-style product data" for the fact that it
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
That is the case for meta_types and __ac_permissions__ but I think you
mistook the fact that "methods" followed a comment that said "handle
old-style product data" for the fact that it was deprecated. But it
never was officially deprecated,
On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote:
> I think that's the sanest policy. So it's OK if "bullshit" gets
> called on people putting deprecation warnings into any .1, .2, etc
> through .9 releases, then? This seems like the only thing that can
> work. We can't exp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lennart Regebro wrote:
> On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
>> The time-based release cycle just amplifies this across many branches
>> and point releases, so nobody really knows which products work with
>> what branch/release and u
On Jun 14, 2006, at 11:35 AM, Andreas Jung wrote:
The general rule for Zope 2 + 3: 1 year = 2 full major releases
according the current half-yr schedule
OK, good!
I never said something like that. I even did not comment on the
this issue
since I have very little insight about the internals
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris McDonough wrote:
> On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote:
>> --On 14. Juni 2006 10:59:09 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
>>
>>> So... you're saying that 2.10 isn't going to be released until December
>>> 2006, the
--On 14. Juni 2006 11:24:45 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
> That would indeed make the deprecation period longer than 1
> year, which seems to have been the intent.
This makes no sense to me.
Let's start clean here.
What interval of time is reasonable for the period
On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote:
>
> --On 14. Juni 2006 10:59:09 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
>
> > So... you're saying that 2.10 isn't going to be released until December
> > 2006, then?
>
> huh? The wiki says June/July...we are just running a bit late
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
So... you're saying that 2.10 isn't going to be released until December
2006, then?
huh? The wiki says June/July...we are just running a bit late with the beta
releases because Philikon needed some time for the ZP
So... you're saying that 2.10 isn't going to be released until December
2006, then? That would indeed make the deprecation period longer than 1
year, which seems to have been the intent.
But wouldn't that make Zope's a yearly release cycle, given that the
first beta of 2.9 was released *last* Dec
On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote:
> If you calculate the deprecation cycle from the day the warning was
> added I agree it is too short.
Whew, I'm not nuts then. ;-)
> Reading the sources I had the impression
> that the fact there was no warning for the deprecated feature was a
--On 14. Juni 2006 10:40:05 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
Hmmm. Then I think someone needs to explain this:
http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus
(Final release late June/early July 2006)
You know that the project wikis were always vapourw
On Wed, 2006-06-14 at 15:44 +0200, Wichert Akkerman wrote:
> Previously Chris McDonough wrote:
> > A year suits me fine if it were the *actual* deprecation period, rather
> > than the six-month deprecation cycle as is the case with zLOG and the
> > eight-month deprecation cycle as is the case with
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
A year suits me fine if it were the *actual* deprecation period, rather
than the six-month deprecation cycle as is the case with zLOG and the
eight-month deprecation cycle as is the case with 'methods'.
zLOG got deprecated for the use of lo
Previously Chris McDonough wrote:
> A year suits me fine if it were the *actual* deprecation period, rather
> than the six-month deprecation cycle as is the case with zLOG and the
> eight-month deprecation cycle as is the case with 'methods'.
I haven't kept track of zLOG (I'm still new to this wor
Hi Chris!
Chris McDonough wrote:
On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote:
No matter what period we decide on it will always be too short for some
and too long for others. With the current setup the deprecation period
is a year, which seems like a decent middle ground.
A yea
On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote:
> No matter what period we decide on it will always be too short for some
> and too long for others. With the current setup the deprecation period
> is a year, which seems like a decent middle ground.
A year suits me fine if it were the *a
On 6/14/06, Max M <[EMAIL PROTECTED]> wrote:
But the problem is that I don't fix bugs that doesn't exist for my
customers. So deprecation warnings are ignored, until the product
sponsor chooses upgrade.
Very reasonable.
If this is how OSS generally works, as I expect, then deprecations will
b
Wichert Akkerman wrote:
Previously Max M wrote:
Except that it hits a sore spot for open source right on the head.
Products are developed for our customers, and they will keep working for
those customers until they choose to upgrade.
But until then you don't upgrade and the changes made in
--On 14. Juni 2006 08:23:53 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
The product I speak of above has 700 individual unit tests and still has
bugs. Shrug. I expect some breakage, and the tests will catch most of
them, and that's fine. But I also have maybe five or six open source
On Wed, 2006-06-14 at 13:34 +0200, Lennart Regebro wrote:
> On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
> Well, ignoring the confusion about zLOG, updating things for a new
> version of Zope with deprecation warnings is not much work. Honestly.
> You update to the new version, look at th
Previously Max M wrote:
> Andreas Jung wrote:
> >At some point you have to make a cut to get rid of old crap. Fixing the
> >zLOG
> >issue is a straight forward approach with very little risks for the
> >programmer and it won't take too much time..I don't see a major problem
> >with that.
>
>
>
On Wed, 2006-14-06 at 13:34 +0200, Lennart Regebro wrote:
> The majority has agreed that the path forward for Zope is to make it
> possible for people to use Zope3 technologies without having to
> rewrite everything from scratch. The changes you see in Zope2 are a
> direct effect of that. You shoul
Andreas Jung wrote:
At some point you have to make a cut to get rid of old crap. Fixing the
zLOG
issue is a straight forward approach with very little risks for the
programmer and it won't take too much time..I don't see a major problem
with that.
Except that it hits a sore spot for open so
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote:
The time-based release cycle just amplifies this across many branches
and point releases, so nobody really knows which products work with
what branch/release and under what configuration some feature is
supposed to emit a deprecation warning
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm sympathetic to that. Change is hard, though and keeping existing
code running is more important to the "Zope brand" than notional API
cleanliness, and it's important to pick your battles.
An example of cruft removal that is worthwhile: the
--On 14. Juni 2006 06:47:37 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Warning: This is gonna be ranty and will almost certainly contain foul
language. ;-)
You're allowed to do so :-)
There was a message sent to the list about deprecat
On Wed, 2006-14-06 at 01:04 +0200, Florent Guillaume wrote:
> Then the framework never gets cleaned up.
I'm actively learning Zope 2 core as much and as quickly as possible so
I can become a more valuable contributor. The less "gunk" I have to
learn about and understand the more quickly I'll beco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Warning: This is gonna be ranty and will almost certainly contain
foul language. ;-)
I've never actually seen a deprecation warning emitted for zLOG. And
I'm about as "in the loop" as anybody could expect someone to be, but
I've not actually
--On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl <[EMAIL PROTECTED]> wrote:
For me, the fact that Zope 2.9.3 still emits
deprecation warnings on a fresh install (zLOG...) is a pretty bad
sign.
I think this is a dead horse now. Some things were deprecated without
actually converting all ins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14 Jun 2006, at 09:44, Andreas Jung wrote:
--On 14. Juni 2006 07:32:42 +0100 Chris Withers
<[EMAIL PROTECTED]> wrote:
I know the good reasoning behind the time-based releases, but have
they
really worked out?
Yes and No.
Yes: It's a must
--On 14. Juni 2006 07:32:42 +0100 Chris Withers <[EMAIL PROTECTED]>
wrote:
Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party
product developers have been ignoring the warning. Their loss.
And this is only for Zope 2.10 which I doubt these third
Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party
product developers have been ignoring the warning. Their loss.
And this is only for Zope 2.10 which I doubt these third party products
are using at the moment.
If we don't remove things at some point
Chris McDonough wrote:
So be it. This is really minor. Not deprecating it is the right thing,
and I won't even qualify that with a "IMO" ;-)
+1
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
__
43 matches
Mail list logo
