Hacker News Reader

Comment by linsomniac | Hacker News Reader

I've been talking to some of the developers on FreeNode about their support of old releases. In particular, related to statements about "Once 1.8 comes out, 1.6 will no longer receive patches". 1.7 came out 9 months ago and 1.8 is in beta. In other words, they don't really have a LTS process.

And the developers seem to think this is totally ok.

In my experience, anything that doesn't have a commitment to at least fixing security issues for ~5 years, isn't a good choice for business. Businesses don't want to tie their internal development and release cadence to an external development team with less than 3 year cycles, ideally 5+.

I've seen it time and again over dozens of companies. There is no time to qualify apps for new major/minor releases. Anything that doesn't have a LTS release story is just not something I can feel good about deploying in my business.

View on HN

> And the developers seem to think this is totally ok.

To be clear the core maintainer-ship of pyramid is about 2-3 people. We would love more contributors to the core codebase, but with that level of commitment we're obviously not able to provide a comparable level of support to a project with more contributors. This is the nature of open source and it is the rare exception to the rule to find packages / projects that have grown to be able to offer such a level of support.

Sure, but this is in a thread that starts with "Django has a new release", so I do think it is relevant considering that Django DOES have LTS releases.

(Aside: mmerickel is the developer I was talking to in Freenode)

Honestly, I didn't know that Pyramid had such a small amount of manpower behind it. It presents itself and has a reputation in the Python community, at least in my experience, of a bigger project.

But, as far as not being able to commit to security releases for old versions: it's obviously a choice in where to spend the available resources, not one of the size of those resources. Choosing new development over providing critical fixes of older releases is a choice, it's just one I need to understand before I commit to using a component. I understand why one would make either of those choices, I just need to know which one has been selected. It is great for people who want to choose forward development focus, I'm just not one of them.

While I'd say that's true as a general rule, an aging system requires a disproportionate amount of time as it ages and the diversity of the platforms underlying stack changes and evolves. This is an issue that would grow exponentially worse over time and being as their team is that small they need to consider risk to their user base when choosing the longevity of their product support. It's quite possible they could support normal issues up to 5 years, but what about the '20 year flood scenario' or 'once in a lifetime flood' if you prefer? What if something that level of bad hits near the 5 year mark and the platform diversity is nearing its maximum diversity?

I believe it's better for them to focus on what they know they can do day in and day out regardless of the circumstances and let companies make the decisions that make sense to them.

In a world where the hardware is written off by the business in 3 years though and websites age out at 3 years and car manufacturers are increasingly trying to hit a 3 year model revision mark it seems to me it's not too much to ask that companies investing hundreds of thousands in an application using Django or Pyramid also invest in maintaining it and keeping it modern or perhaps their existing business model needs additional revision too.

Just a thought as the least informed member of HN.

But you think about this in a wrong way - pyramid is a "glue" framework, unlike django.

- request/response (webob) gets its own updates.

- templates get their own updates.

- sqlalchemy gets its own updates Etc.

You WILL get security fixes for most of your application even without upgrading the framework itself (the attack surface for pylons/pyramid itself is smaller than monolith).

By being on a lower version you don't really miss much - the API's are very stable. And 99% of time you can update pyramid version itself without risking application breakage (the chance of it is probably a lot lower than with monolithic framework).

I know about very heavy websites that are still using pylons(precursor to pyramid) in production without issues (8 years now).

... then isn't it not a big deal to commit to security updates?

Sure, as far as i can tell it was always being updated so far - even without written commitment.

Reply on news.ycombinator.com