<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 3:50 PM, Matt Chapman <span dir="ltr"><<a href="mailto:Matt@ninjitsuweb.com">Matt@ninjitsuweb.com</a>></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;">
<br><div class="im">
> That seems incredibly unfair to clients, especially those with limited<br>
> budgets.<br>
</div>To me, it is incredibly unfair to the client to claim to be saving them<br>
money by giving them an obsolete solution which is prone to security<br>
vulnerabilities.</blockquote><div><br>So, just because they upgrade they are more secure? Any version of Drupal is prone to security vulnerabilities. Flaws are found and fixed, and hopefully you patch. If your code base is no longer being actively maintained, it doesn't mean you can't attempt to apply the same patch or create your own with the identified flaw.<br>
<br>Lets look at it from this standpoint. We upgrade for two reasons, 1. Lack of support for security fixes. 2. There is new functionality we wish to take advantage of. Now if reason 1 goes away because vulnerable that are found are fixed no matter what the version, then if you have not need to new functionality at the moment, why spend the money to upgrade? Especially if you don't wan to change anything. So the website might be a living organism, but maybe for the next three years the customer doesn't want squat done for whatever reason. <br>
<br>I do think the consultant is responsible for letting the customer know how Drupal is structured as a FOSS from a releasing standpoint. They should explain the advantages, disadvantages and risks. Based on the customer help them make the right decision. <br>
<br>On last thing to look at, when Drupal 5 EOLs. If we don't get a security flow for 1 year, is the website any more or less secure in that year?<br></div></div><br>-- <br>Christian<br>