Thanks for the detailed response. I didn't think to look to Red Hat's to see if they backported security fixes, so that's good to know.
As for the undefined behavior with respect to less-than idiomatic programming, I think that's something we'll definitely need to keep in mind and hopefully be able to enforce with code reviews. I've personally been wanting to use SQLAlchemy, but it's important we understand implications for decisions like this when the lifetime of code is guaranteed to surpass a decade. I'm pretty sure we'll end up using SQLAlchemy for the long term. Thanks again, Brian On Apr 18, 2015, at 2:47 PM, Mike Bayer <mike...@zzzcomputing.com<mailto:mike...@zzzcomputing.com>> wrote: On 4/17/15 6:58 PM, Van Klaveren, Brian N. wrote: Hi, I'm investigating the use and dependency on SQLAlchemy for a long-term astronomy project. Given Version 1.0 just came out, I've got a few questions about it. 1. It seems SQLAlchemy generally EOLs versions after about two releases/years. Is this an official policy? Is this to continue with version 1.0 as well? Or is it possible 1.0 might be a something of a long-term release. 2. While well documented and typically minimal, SQLAlchemy does have occasional API and behavioral changes to be aware of between versions. Is the 1.0 API more likely to be stable on the time frame of ~4 years? Put another way, would you expect that it should be easier to migrate from version 1.0 to the 1.4 (or whatever the current version is) of SQLAlchemy in five years than it would be to migrate from 0.6 to 1.0 today. I know these questions are often hard to answer with any certainty, but these sorts of projects typically outlive the software they are built on and are often underfunded as far as software maintenance goes, so we try to plan accordingly. (Of course, some people just give up and through everything in VMs behind firewalls) Well the vast majority of bugs that are fixed, like 99% of them, impact only new development, that is, they only have a positive impact someone who is writing new code, using new features of their database backend, or otherwise attempting to do something new; they typically only serve to raise risk and decrease stability of code that is not under active development and is stabilized on older versions of software. These kinds of issues mean that some way of structuring tables, mapped classes, core SQL or DDL objects, ORM queries, or calls to a Session produce some unexpected result, but virtually always, this unexpected result is consistent and predictable. An application that is sitting on 0.5 or 0.6 and is running perfectly fine, because it hasn't hit any of these issues, or quite often because it has and is working around them (or even relying upon their behavior) would not benefit at all from these kinds of fixes being backported, but would instead have a greater chance of hitting a regression or a change in assumptions if lots of bugfixes were being backported from two or three major versions forward. So it's not like we don't backport issues three or four years back because it's too much trouble, it's because these backports wouldn't benefit anyone and they would only serve to wreak havoc with old and less maintained applications when some small new feature or improvement in behavioral consistency breaks some assumption made by that application. As far as issues that are more appropriate for backporting, which would be security fixes and stability enhancements, we almost never have issues like that; the issues we have regarding stability, like memory leaks and race conditions, again typically occur in conjunction with a user application doing something strange and unexpected (e.g. new development), and as far as security issues the only issue we ever had like that even resembled a security issue was issue 2116 involving limit/offset integers not being escaped, which was backported from 0.7 to 0.6. Users who actually needed enterprise-level longevity who happened to be using for example the Red Hat package could see the backport for this issue backported all the way to their 0.5 and 0.3 packages. But presence of security/memory leak/stability issues in modern versions is extremely rare, and we generally only see new issues involving memory or stability as a result of new features (e.g. regressions). There's also the class of issues that involve performance enhancements. Some of these features would arguably be appropriate to backport more than several major versions, but again they are often the result of significant internal refactorings and definitely would raise risk for an older application not undergoing active development. An older application that wants to take advantage of newer performance features would be better off going through the upgrade process than risking running on top of a library that is a hybrid of very old code and backported newer approaches, which will see a lot less real-world testing. So short answer, the EOL you see of those old versions is generally a good thing as those old versions are running in old applications that aren't seeing lots of new development and would see a mostly negative effect and little to no benefit from the code continuing to change. SQLAlchemy is a development library so generally an application that's been put into production against a certain version has been well tested and tuned against the behaviors of that specific version. As far as API and behavioral changes, as far as API we are really conservative about actually changing APIs such that an older approach won't work anymore. That happened a lot in the early days, e.g. from 0.1, 0.2, 0.3 up through 0.5, then after 0.5 there were still a few large ones that had to go, these would be "entity name" and "mutable types", which really had a very negative impact on the ORM. We avoid having to actually remove an old API to a very high degree and we always provide for a comprehensive deprecation and upgrade path. Legacy APIs like the MapperExtension, SessionExtension systems, the ThreadLocal engine, things like that, basically never go away, as long as we can set them aside and express their internals in terms of newer systems, they'll never be removed. The Extension classes have been deprecated for four years but are still supported and tested. Where the upgrade path is actually problematic in modern versions falls under two categories; a regression in SQLAlchemy itself, because a change in a system did not anticipate how it was being used in the real world, or because a real world application was relying upon broken behaviors which we eventually had to change. Which means that an application that uses SQLAlchemy in a more idiomatic way will not have much less impact from major releases and in fact we've seen very large and expansive applications like Openstack and others move from 0.7 to 0.8 to 0.9 with very little issue. The features and behavioral consistencies we focus on in each new major version, not to mention continuous work on the documentation, helps to make idiomatic use of SQLAlchemy more natural and convenient each year. I can't tell you what decision you should make but hopefully this gives some background on the thinking behind SQLAlchemy's approach towards change. Brian -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email tosqlalchemy+unsubscr...@googlegroups.com<mailto:sqlalchemy+unsubscr...@googlegroups.com>. To post to this group, send email to sqlalchemy@googlegroups.com<mailto:sqlalchemy@googlegroups.com>. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
