What this thread has answered is how this all works on a practical level.  <br><br>Here&#39;s an example.  A client comes to me with specs for a site.  I decide to built in D6, and let&#39;s just say, the total cost is $5,000, because it relies very little customization.  I&#39;m using about 15 contributed modules too do almost everything they want. .<br>
<br>Now how exactly do I tell the client that D6 site may reach it&#39;s end of life in 2 years -- and more importantly, how to tell them how much it will cost in two years -- or over a 5 year period?<br><br>When D6 reaches EOL, the 15 modules may or may not have been ported to D7.  In fact, some may have abandoned..  So in two years, upgrading the site, in a best case scenario, maycost the client  $500 or, because, say, there&#39;s no Ubercart in Drupal 7 or 8,  it might cost $20,000, because all those nice Ubercart modules I used aren&#39;t around any more.  <br>
<br>I mean its hard enough coming up with an estimate to built a site in the current version of Drupal.  If the current version is going to be obsolete in a couple of years, I don&#39;t see you build that cost in as well, when you have no idea whether or not the contributed modules you are using today will be available tomorrow.  <br>
<br>Or when you don&#39;t know how long the custom code, that uses all those great hooks and depends on other modules, is going to have to be rewrriten due to changes in the core and in those modules.  <br><br>If folks are saying the right practice is to keep sites current and not run them on versions of Drupal no longer supported by the community, it does raise the issue of how exactly this works in everyday practice.  <br>
<br>Sam<br><br><div class="gmail_quote">On Mon, Mar 30, 2009 at 3:30 AM, Sean Burlington <span dir="ltr">&lt;<a href="mailto:sean@practicalweb.co.uk">sean@practicalweb.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Bill Fitzgerald wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Whenever I hear someone say:<br>
<br>
&quot;Drupal should maintain backward compatibility&quot; I hear &quot;It&#39;s inconvenient for me that some individual or company from within the Drupal community doesn&#39;t maintain backward compatibility.&quot;<br>
<br>
Whenever I hear someone say:<br>
<br>
&quot;Drupal should maintain versions from X years ago&quot; I hear &quot;It would be convenient for me if some individual or company from within the Drupal community maintained versions from X years ago.&quot;<br>
<br>
</blockquote>
<br></div>
What I said was<br>
<br>
-----<br>
Because Drupal has expanded a lot over recent years and has been adopted by some big sites - surely there is a stronger argument than in the past for longer term support.<br>
<br>
So maybe the existing security team won&#39;t take it on - but if there are enough people in the community who do want to support D5 for longer then I can&#39;t see why anyone else in the community would want to prevent this. -----<br>

<br>
As Shai says - maybe we&#39;re not so far apart.<div class="im"><br>
<br>
<br>
<br>
<br>
-- <br>
<br>
Sean Burlington<br>
<br>
<a href="http://www.practicalweb.co.uk" target="_blank">www.practicalweb.co.uk</a><br>
<br>
<br>
<br>
_______________________________________________<br></div><div><div></div><div class="h5">
consulting mailing list<br>
<a href="mailto:consulting@drupal.org" target="_blank">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
</div></div></blockquote></div><br>