Exactly, and if we start include external libs; wouldn't it make harder for users to upgrade the libs? One wet dream for many developers is to control what version of everything your running. It's possible/likely that we will face a situation where module maintainers will encourage to use their shipped version only.
<br><br>If the users have to fetch the libs from an external source, they will most likely get the most recent version. But on the other hand, they wont probably upgrade them after that, even if they keep their modules up to date.
<br><br><br><div><span class="gmail_quote">On 5/21/07, <b class="gmail_sendername">Jeff Eaton</b> <<a href="mailto:jeff@viapositiva.net">jeff@viapositiva.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
it isn't "very simple;" security patches are just one aspect of issue.<br><br>What about the fact that Drupal, despite its breakneck pace, moves<br>SLOWER than some other GPL projects? In those scenarios, we actually
<br>need to keep an older version for compatibility issues.<br><br>--Jeff<br><br><br>On May 21, 2007, at 2:08 PM, Karoly Negyesi wrote:<br><br>>> I don't understand what's so inconvenient in allowing external files.
<br>><br>> It's very simple. When there is a security fix released for the 3rd<br>> party code then our repository necessarily will be some time behind<br>> -- if the maintainer is sloppy then seriously behind. I do not want
<br>> Drupal distributing insecure code. Solve this problem and we can<br>> move on.<br><br></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br> Johan Forngren :: <a href="http://johan.forngren.com/">http://johan.forngren.com/
</a>