[infrastructure] Re: [development] Drupal 4.5 unsupported

[Jonathan Lambert]

> And since people (at least the ones I know) expect their site
> to last longer than 12 months they will inevitably find
> themselves using an insecure, unsupported version of Drupal.

That just happens to be an unrealistic expectation for Drupal (or most OS
CMS systems) at this time.  Look, you're missing my point.

The point is that to use Open Source systems you have to take the good with
the bad.  Want access to the latest technology?  Upgrade.  Want the latest
security patches?  Upgrade.  If you want a longer support timeframe, go
commercial.  OR, get with the program.  You're on an Open Source platform.
You will have to upgrade.

Drupal could do better on backwards compatibility sure.  But you wouldn't
have the forms api in core on 4.7; you wouldn't have nearly as much cool
stuff.  To get this cool stuff, you have to?  Upgrade!

If you need a longer support horizon, use a commercial alternative.  Open
Source platforms have a cost - it's time investment.  You have to invest in
upgrades.  If you can't do upgrades, you pay with dollars.

That's just the economics of Open Source.  Hardly worth arguing about
really.

>> If anything, we need to get
>> more customers on a daily or weekly upgrade, and build systems to help
>> drive upgrades that make it easier to do so.
> 
> I don't see how this would be possible with anything but
> a trivially simple site that used nothing but core modules.
> 
You snipped the answer right from my post!

"move forward towards continuous integration and test-driven development, so
changes can be more rapidly integrated into consuming sites"

Change management, and I can tell you since my job every day is to oversee a
lot of very high traffic Drupal websites, is the holy grail of Open Source
systems and the emerging hosting/SaaS businesses around the model.  It's not
solved yet.  There is no "way", other than the "way of the keyboard" (so
called "manual mode" ;-) to handle upgrades.

However, continuous integration and test-drive development mean you can keep
your site up-to-date until it breaks, then fix whatever broke it.

I just think that those folks who want to fragment the 4.5 user group, and
build support for old releases simply don't like the answer, not that the
answer isn't there.

The answer, plain and simple, is that it's the cost of doing business on
Open Source platforms.

> But any site that uses a contrib module has to wait for
> that module to be updated. Any site which has custom code
> that depends on a changed part of the API will break.

False.  Any site that uses a contrib module has to wait for that module to
be updated, OR pay for someone to update it, OR update it themselves.  Look,
the core foundation of Open Source is that users participate in ongoing
development.  If you find yourself waiting on a core developer to update a
patch, update it yourself or start nicely harassing the module maintainer
(believe me, it's motivating to hear from users!).

This is an inherent weakness in Drupal's current model, so in fact Drupal
should move to correct the problem, not move to build a process to keep the
problem from recurring.  Another way of looking at this problem is that core
modules should be tied to a revision of the API, so that they do not break
until upgrades, so perhaps the API should be versionable!  Wouldn't that
solve the problem as well?

Does anyone remember the pain of moving from glibc was?  I remember seeing
so many 'GLIBC_2.2' not found errors, I was losing hair!  This was the same
problem in Linux!  The same exact problem.  Or moving from php 4.0.x to
4.1.x or 5.0.x?  Oh man, does that break a lot of stuff.  So does that mean
we should create a php version that's supported so that nobody has to
upgrade?  Not inherently.

The fact is that a supported php version that's for older releases makes
more sense than an older Drupal version, as it would affect a huge number of
Open Source customers and in fact has a massive diseconomy for non-support.
But they still don't do it!  Why not?

My point is that looking at today's problems with today's eyes isn't what
this platform is all about, and you can't actually see the forest for the
trees when you're invested in a particular revision of a product.  You need
to step beyond your "project scope", and into "Open Source" scope, and
realize that the need to upgrade comes from the very vitality and growth of
the platform you are using.

Also, the arguments for support of old platforms miss an important economic
point.  The different in cost in moving from 4.5 to 4.6 OR from 4.5 to 4.7
are an order of magnitude larger.  It's a MASSIVE effort, as you have to
upgrade twice, and one of those times stabilize a system (and associated
modules) without any material benefit to the site.  That's a terrible waste
of time.  It's much cheaper just to stay with current releases, absorb the
annoyance that comes with frequent upgrades, and avoid all the pitfalls I
have laid out already.

 
> All you'd be doing by pushing weekly updates is spreading
> the pain of an upgrade out so that you have a little pain
> every week rather than one massive ache every 6 months.

No, continuous integration would mean you'd have really no pain unless it
broke, and then you could roll back until you wanted to fix why it broke.
It's a completely different way of looking at software, and is much more
oriented towards modern platforms that look less like "webware" and more
life software, of which Drupal is fast becoming a material participant.

> Either way, using Drupal hurts.

Got something better?

Jonathan