On 6/19/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Hmm, perhaps browser:defaultView isn't such a bad idea then... :).
Actually, I don't have much of an opinion, to be honest. I just thought
that it would make sense that browser:defaultView only modified the
behaviour of Zope 3 views.
Philipp von Weitershausen wrote:
Lennart Regebro wrote:
On 6/18/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
The remaining important question is: if a *default* view is specified
using the zope 3 mechanism, should we always treat it as a zope 3 view,
and refuse to lookup an attribute
Florent Guillaume wrote:
Philipp von Weitershausen wrote:
Lennart Regebro wrote:
On 6/18/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
The remaining important question is: if a *default* view is specified
using the zope 3 mechanism, should we always treat it as a zope 3
view,
and
Jens Vagelpohl wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16 Jun 2006, at 10:28, Andreas Jung wrote:
My recommendation:
1 yr deprecation period as it is now
1 yr + X maintenance period for older branches.
+1
Extending the maintenance period for older branches indeed sounds
Florent Guillaume wrote:
If anyone with greater knowledge could implement the above without
much pain, that'd be great. In any case, hopefully Google will catch
this some time and save the next weary traveller who bumps into it a
couple of hours ;-)
How about opening a ticket in the
Lennart Regebro wrote:
Only because we have more stable releases,
only? That's the big problem here ;-)
1. That's all well and good until you _need_ some feature like MVCC and
are then forced to do an upgrade which breaks prettymuch every one of
your products.
And the difference is that
Lennart Regebro wrote:
On 6/18/06, Paul Winkler [EMAIL PROTECTED] wrote:
+1, I'd like some way to easily know when a release is no longer
maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release.
Unless we decide to change that
Martijn Faassen wrote:
+1
Extending the maintenance period for older branches indeed sounds like a
good idea.
Hang on, that makes things even worse for the already-stressed
developers though. The branches there are combined with the longer
they're stable for gives you the developer
Christian Theune wrote:
However, Zope 2.8 is still available for stable download ... so we
currently have 7 branches to watch out for.
...and you're not even including ZODB branches and the like that need to
be maintained and kept in sync...
Chris
--
Simplistix - Content Management, Zope
On 19 Jun 2006, at 14:59, Chris Withers wrote:
Florent Guillaume wrote:
If anyone with greater knowledge could implement the above
without much pain, that'd be great. In any case, hopefully Google
will catch this some time and save the next weary traveller who
bumps into it a couple of
Chris Withers wrote:
Philipp von Weitershausen wrote:
Note that this should also extend to the Zope 3 releases. Zope 3.2 is
part of Zope 2.9 and will hence be used for quite some time. Yet,
bugfixes aren't even backported to the Zope 3.2 branch anymore...
It's this sort of thing that makes
Florent Guillaume wrote:
Hopefully the google archive trail will be enough for this issue...
When I look for bugs to fix I don't read the mailing list archives for
the past two years, I use the collector.
Funny, I usually start by googling...
Chris
--
Simplistix - Content Management, Zope
Philipp von Weitershausen wrote:
Uh, never mind.
+1 :)
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 Jun 2006, at 15:51, Chris Withers wrote:
Florent Guillaume wrote:
Hopefully the google archive trail will be enough for this issue...
When I look for bugs to fix I don't read the mailing list archives
for the past two years, I use the
Jens Vagelpohl wrote:
Use the collector. It is *the* place where people go to look for things
to fix. What length of time it takes to fix is a totally separate issue.
Bugs that get posted on mailing lists get ignored unless they are the
world is coming to an end type bugs.
Read the thread,
Chris Withers wrote:
Martijn Faassen wrote:
+1
Extending the maintenance period for older branches indeed sounds like
a good idea.
Hang on, that makes things even worse for the already-stressed
developers though. The branches there are combined with the longer
they're stable for gives
Chris Withers wrote:
[snip]
One of my other bugbears is that a flood of deprecation warnings often
masks real problems.
What real problems?
How would people feel about the default zope.conf hiding all deprecation
warning?
-1
This is bad. You'd be making it far less likely people will
On 6/19/06, Chris Withers [EMAIL PROTECTED] wrote:
Well, it's 2 versions, so far. I.e, current release and last release.
Unless we decide to change that now.
Is it really?
That's how it has been so far, yes. Maybe we should extend it. But
mind you, that's more work...
I for one, is NOT
On 6/19/06, Lennart Regebro [EMAIL PROTECTED] wrote:
I for one, is NOT interested in backporting fixed in Five trunk to
both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current
versions of Five if we say that Zope 2.8 and 2.7 should be still
supported after the release of 2.10. If
--On 19. Juni 2006 16:25:32 +0200 Lennart Regebro [EMAIL PROTECTED] wrote:
I for one, is NOT interested in backporting fixed in Five trunk to
both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current
versions of Five if we say that Zope 2.8 and 2.7 should be still
supported after
20 matches
Mail list logo
