Hi Adam
> Behalf Of Adam Groszer
> Sent: Tuesday, May 16, 2006 8:32 AM
> To: zope3-dev
> Subject: [Zope3-dev] BBB
>
> Hi there,
>
> I'm working on removing BBB warnings of our current app for 3.3.
> For the directive it was possible to give the
>
Hi there,
I'm working on removing BBB warnings of our current app for 3.3.
For the directive it was possible to give the factory some
parameters like this:
Now, with the directive that's not possible.
--
Best regards,
Adam mailto:[EMAIL PROTECTED]
--
Quote of the d
For me one year is fine as a deprecation period. I feel that sites
should be kept stable when working, and then, after maybe a year or
two or more, when needed, moved to a new and updated system. If you
then have special software, you'll need to update it.
If we want those types of updates to work
Benji York wrote at 2006-1-4 14:22 -0500:
>Dieter Maurer wrote:
>> Jim Fulton wrote at 2006-1-3 14:41 -0500:
>>>I think 12 months is a bit short. I don't think the backward-compatibility
>>>code
>>>is that burdonsome, once written. What do other folks think?
>>
>> If the backward compatibility
Tim Peters wrote at 2006-1-4 14:51 -0500:
>[Dieter Maurer]
>> If the backward compatibility period gets shorter,
>> we will skip more and more releases because of the increased burden
>> to get our applications running again...
>
>Well, every new release will remove features deprecated N releases
>
[Dieter Maurer]
> If the backward compatibility period gets shorter,
> we will skip more and more releases because of the increased burden
> to get our applications running again...
Well, every new release will remove features deprecated N releases
ago, where N is presumably some constant whose va
Dieter Maurer wrote:
Jim Fulton wrote at 2006-1-3 14:41 -0500:
I think 12 months is a bit short. I don't think the backward-compatibility code
is that burdonsome, once written. What do other folks think?
If the backward compatibility period gets shorter,
we will skip more and more releases b
Jim Fulton wrote at 2006-1-3 14:41 -0500:
> ...
>I think 12 months is a bit short. I don't think the backward-compatibility
>code
>is that burdonsome, once written. What do other folks think?
If the backward compatibility period gets shorter,
we will skip more and more releases because of the i
Hi,
Am Dienstag, den 03.01.2006, 14:41 -0500 schrieb Jim Fulton:
> > As much as BBB code annoys me personally, I think maintaining a minimum
> > compatibility window is necessary for an important class of user.
>
> I think 12 months is a bit short. I don't think the backward-compatibility
> co
Benji York wrote:
Stephan Richter wrote:
On Tuesday 03 January 2006 13:33, Benji York wrote:
> As a corollary, it would be time now to remove the BBB that should be
> removed for 3.3. Should we wait for 3.4?
Following the rules above, if 3.3 will be released more than 12 months
since the rel
Stephan Richter wrote:
On Tuesday 03 January 2006 13:33, Benji York wrote:
> As a corollary, it would be time now to remove the BBB that should be
> removed for 3.3. Should we wait for 3.4?
Following the rules above, if 3.3 will be released more than 12 months
since the release of 3.1, it would
On Tuesday 03 January 2006 13:33, Benji York wrote:
> > As a corollary, it would be time now to remove the BBB that should be
> > removed for 3.3. Should we wait for 3.4?
>
> Following the rules above, if 3.3 will be released more than 12 months
> since the release of 3.1, it would be OK to remov
Stephan Richter wrote:
> So let's make the deprecation support also time-based. What time would
> you prefer?
I would prefer two releases and a minimum of 12 months. That way if
the time-based releases slip, we still guarantee two releases with
backward compatible code. If we release more often
Hi all,
now that we switched to time-based releases, it seems that our policy to
support old API for two more 3.x releases is not appropriate anymore. Two
release cycles are now only 12 months long, which seems a bit short. So let's
make the deprecation support also time-based. What time would
14 matches
Mail list logo
