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
necessa
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 histo
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
develo
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
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 n
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 o
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,
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
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
--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 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
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
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.
>
>
>
24 matches
Mail list logo
