Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200:
... deprecation policy ...
This policy allows us to move forward (which Zope 2 never
really did for the the majority of those five years you mention).
Although, it might help in a few cases, it is not at all
Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200:
... deprecation policy ...
This policy allows us to move forward (which Zope 2 never
really did for the the majority of those five years you mention).
Although, it might help in a few cases, it is not at all
necessary to cast ones history
Dieter Maurer wrote:
* cutting down the amount of code duplication and duplicated frameworks.
We've had two ZPT implementations, now we have to maintain only one. We
had our own logging framework, now we can simply use Python's, etc.
The second logging framework (zLOG) was a tiny wrapper
Chris Withers wrote:
Tres Seaver wrote:
Unit test coverate for custom products is actually quite good. The
problems are nearly always to do with third party products, many of
which have been in useful stable mode since long before either
deprectaions or ubiquitous unit testing were part of
Philipp von Weitershausen wrote at 2006-6-18 12:28 +0200:
...
Its configuration was documented in the Zope schema file.
Its single API method was self explaining...
Not everybody is as smart as you are, Dieter.
Thank you :-)
And certainly not everyone
would get the idea of reading code or
Tres Seaver wrote:
Unit test coverate for custom products is actually quite good. The
problems are nearly always to do with third party products, many of
which have been in useful stable mode since long before either
deprectaions or ubiquitous unit testing were part of our community's
Dieter Maurer wrote:
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
Tres Seaver wrote:
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 under what configuration some
Lennart Regebro wrote:
So this is not a problem with deprecation period, time based releases
or anything else, then.
No, but the slew of deprecation warnings, proliferation of branches that
need to be supported (regardless of whether they're officially
production or not) and sheer amount of
Chris Withers wrote:
Lennart Regebro wrote:
So this is not a problem with deprecation period, time based releases
or anything else, then.
No, but the slew of deprecation warnings, proliferation of branches that
need to be supported (regardless of whether they're officially
production or
On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote:
We've had two ZPT implementations, now we have to maintain only
one. We
had our own logging framework, now we can simply use Python's, etc.
These changes may seem cosmetic to the outside developer (he has to
use
different APIs),
Chris McDonough wrote:
On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote:
We've had two ZPT implementations, now we have to maintain only one. We
had our own logging framework, now we can simply use Python's, etc.
These changes may seem cosmetic to the outside developer (he has to
On 15 Jun 2006, at 16:09, Philipp von Weitershausen wrote:
Chris McDonough wrote:
People will get sick of seeing the warnings, and they'll
eventually change it, but there's just no reason to *force* them to
change it on our time schedule. And if they don't, who cares?
People
who don't want
On Jun 14, 2006, at 5:30 PM, yuppie wrote:
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
On Jun 15, 2006, at 10:09 AM, Philipp von Weitershausen wrote:
Well, except that the actual, formal deprecation of zLOG finally made
everyone aware of the logging module and a few things like logging
levels that no one had thought about till then. So I wouldn't say the
benefit was exactly
Chris McDonough wrote at 2006-6-14 14:50 -0400:
...
PsycoPG-DA does, MySQLDA does, one of my products named
ZopeMailArchive does.
CCSQLMethods does (because until very recently ZSQLMethods did,
hopefully changed now).
--
Dieter
___
Zope-Dev
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
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 should
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
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
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
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
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 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
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 bug
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*
--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 ZPT
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 with the
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, nor
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 was
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
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.
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
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*
34 matches
Mail list logo
