Using alpha software in production [was Re: Trying tcompile an use the Python 3.4a]

[Steven D'Aprano]

On Thu, 14 Nov 2013 12:27:58 +1100, Chris Angelico wrote:

> On Thu, Nov 14, 2013 at 12:14 PM, Denis McMahon
> <denismfmcmahon at gmail.com> wrote:

>> Nobody is so stupid as to run alpha software on a production server[1]
>> are they?
>>
>> [1] In this context, "production server" means any system facing the
>> public internet upon which python code is executed in response to
>> inputs from the public internet.

Surely the answer to that is, "define stupid"?

What are the consequences of breakage? If the consequences are minor, why 
wouldn't I use alpha software? Hypothetically speaking, even if the 
machine were totally compromised, I might just shrug and rebuild it 
(hopefully having reported the security vulnerability that allowed the 
compromise, and having it fixed).

But specifically in this case, I agree with your implication, and 
question the wisdom of the OP upgrading from a stable version of 3.3 to 
an alpha version of 3.4.


> I don't know that that's necessarily stupid. For a lot of my work, I've
> been using a trunk version of Pike (7.9.11 currently), and if I were
> working more heavily with Python on my servers, I would consider using
> alpha versions if there were features that I wanted (or fixes that I
> needed). It's not stupid, but it does require a "hand on the tiller" so
> to speak; running alpha code - or, for that matter, any code you
> compiled yourself - in production means taking responsibility for it.

Yes, this! A master craftsman knows when to break the rules. I personally 
would not run a public web app using alpha software because I know my 
limitations, but I'm sure there are those who have both the skill to 
manage it and the wisdom to know whether or not to risk it.


> I'm confident of my own ability to keep up with changes, but for most
> people, I would strongly recommend taking, in order: (1) the Python that
> your distro provides; (2) a python.org published stable version; (3) a
> preproduction (eg RC) version; and finally (4) anything else, including
> straight from Mercurial. The further down that list you go, the more
> work you have to do yourself to ensure compatibility, dependency
> management, etcetera.

+1


-- 
Steven