For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Following another informal policy, we were going for an 18 months
release cycle at some time (2.6 clearly took longer), which would
mean
On 2008-08-14 08:43, Martin v. Löwis wrote:
For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Since we don't have a fixed release cycle, making the 2.(n-1)
maintenance time frame depend
On Thu, Aug 14, 2008, M.-A. Lemburg wrote:
On 2008-08-14 08:43, Martin v. L?wis wrote:
For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
My view is that they should be closed when 2.7 and 3.1 are released.
Since we don't have a fixed release cycle, making
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries are provided - thus,
On 2008-08-13 04:57, Guido van Rossum wrote:
And there's a reason for this slow uptake of Python 2.5: as more
and more servers run 64-bit OSes, the Py_ssize_t changes cause
serious trouble with Python C extensions that were not updated
by their authors.
I'm not sure what that has to do with
M.-A. Lemburg wrote:
On 2008-08-13 07:53, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries
On 2008-08-13 15:20, Steve Holden wrote:
M.-A. Lemburg wrote:
Perhaps we should just document the maintenance of Python releases
more clearly and also plan for a final bug fix release 3 years after
the initial branch release. That way developers and users can also
adjust their plans
Why not migrate support for older releases to interested parties outside of
the regular developer team? Presuming there is someone out there with the
interest in maintaining, say, Python 2.2, they could take over the entire
responsibility for making releases, continuing to use the Subversion
It's difficult to use such download numbers as hint for the number
of deployed installations. 2.4.5 was not released as binary, so
interested parties had to compile that version by themselves and
those installations don't show up in your statistics.
You mean, they installed it *without*
On 2008-08-13 22:32, Martin v. Löwis wrote:
It's difficult to use such download numbers as hint for the number
of deployed installations. 2.4.5 was not released as binary, so
interested parties had to compile that version by themselves and
those installations don't show up in your statistics.
What I was trying to say is that you only see a single source download,
which someone then takes, compiles and possibly redistributed or
integrates into a product. As a result a single download can
easily map to quite a few installations - and that's what we should
base our assumptions on.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 1:53 AM, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 10:29 AM, [EMAIL PROTECTED] wrote:
Why not migrate support for older releases to interested parties
outside of
the regular developer team? Presuming there is someone out there
with the
interest in maintaining, say, Python
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such branch can still be added now. Nothing
that gets added to the source repository ever becomes
On Wed, Aug 13, 2008 at 4:11 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such branch can still be added
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 13, 2008, at 7:11 PM, Martin v. Löwis wrote:
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such
Because there won't typically be sufficient testing and release
infrastructure to allow arbitrary bug fixes to be committed on the
branch. The buildbots are turned off, and nobody tests the release
candidate, no Windows binaries are provided - thus, chances are very
high that a bug fix
17 matches
Mail list logo
