[Bf-committers] Moving to Python 3.2.x
ideasman42 at gmail.com
Wed Mar 9 01:13:44 CET 2011
On Tue, Mar 8, 2011 at 11:25 PM, Matt Ebb <matt at mke3.net> wrote:
> On Wed, Mar 9, 2011 at 10:00 AM, Martin Poirier <theeth at yahoo.com> wrote:
>> Unless the benefits outweighs the hindrances, there's nothing lost by waiting until the next minor release.
> This sounds sensible to me. Considering the widespread inconvenience
> caused by these sorts of things, it would seem that unless there's
> something dire that needs to be fixed by an update immediately, then
> it would be much better to wait a while so people can build from their
> linux distros easily, so that people using external modules don't get
> stuck, and so that any new bugs brought in by a new Python version can
> be avoided.
> Just because a new Python version is released doesn't mean that
> blender needs to start using it immediately - many 3d apps are still
> using Python ~2.5. Like Martin said, it's a case of benefits vs
> hindrances, and as time goes by and more people are getting on board
> with Python in Blender 2.5, the hindrances side of the equation is
> getting heavier and heavier, which means these changes need to be
> approached with a greater level of sensitivity and care. I feel this
> also applies to API changes now too. I'm not against change in itself,
> but I do feel that the current degree of external costs in the
> cost/benefit relationship isn't being given serious enough treatment.
As said before in the last mail, its fairly arbitrary when we upgrade.
But I'd really not want to have to worry about maintaining 2 versions
of python for more then a months, two months at most.
We can upgrade python without causing too much inconvenience just be
ensuring we document how to install the latest python.
I thought that documenting how to build python would be enough, but it
seems us bearded linux geeks who like to compile blender from source
are for some reason not ok about building python.
ok, we can include instructions for getting python testing packages too.
Heres my proposed policy for major upgrades...
--- copying main points from the wiki.
* Linux platform maintainers first agree to drop support.
* Include a note in meeting minutes beforehand that the python version
will be no longer supported.
* Ensure build instructions are up to data for Ubuntu/Fedora to
install packages (most likely from testing repo's).
regarding API stability, rather discuss that separately.
More information about the Bf-committers