While I agree with the substance of what your are saying here, I would be careful with the word &quot;marginalize&quot;.<br><br>While I would strongly support a default filter that only includes stable releases (which is reasonable, and would be a big help for everyone, as would the oft-discussed points system, which admittedly would be hard to implement), you still want to encourage people to publish dev versions of modules, without putting a time limit on how long it takes for a stable version of that module to come out (for a whole variety of reasons discussed here).<br>
<br>People should not use modules which don&#39;t have stable releases, as Miles says.<br><br>But a stable, active, development community needs to encourage experimental modules also, many of them need the involvement of the community in order to flourish. And sometimes that takes time, also. So I think &quot;marginalize&quot; is a poor choice of words.<br>
<br>But definitely, non-developer users should be steered clear of experimental work which is mainly of interest to developers.<br><br>saludos,<br><br>Victor Kane<br><a href="http://awebfactory.com.ar">http://awebfactory.com.ar</a><br>
<br><div class="gmail_quote">On Feb 18, 2008 4:16 PM, Moshe Weitzman &lt;<a href="mailto:weitzman@tejasa.com">weitzman@tejasa.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The Drupal Association and the Security have discussed off and on how<br>to improve the security of Contrib and the effectiveness of our update<br>mechanism. And you are right that we are considering changes to how<br>modules without stable releases are listed on <a href="http://drupal.org" target="_blank">drupal.org</a>. We also<br>
discussed how update module should handle them. You can bet that any<br>changes we make will further marginalize these modules, since they<br>operate outside of update module which is a very bad thing.<br><div><div></div>
<div class="Wj3C7c"><br>On Feb 18, 2008 11:56 AM, Xavier Bestel &lt;<a href="mailto:xavier.bestel@free.fr">xavier.bestel@free.fr</a>&gt; wrote:<br>&gt;<br>&gt; On Mon, 2008-02-18 at 08:49 -0800, Earl Miles wrote:<br>&gt; &gt; Ashraf Amayreh wrote:<br>
&gt; &gt; &gt; Sometime I think this should become a requirement rather than something<br>&gt; &gt; &gt; optional, all current dev releases could be promoted to a first release<br>&gt; &gt; &gt; and new dev releases banned.<br>
&gt; &gt;<br>&gt; &gt; No, because during active development it is really convenient to have<br>&gt; &gt; the -dev releases available.<br>&gt; &gt;<br>&gt; &gt; I agree that it is inconvenient that sloppy module maintainers do not<br>
&gt; &gt; create releases. However, this is my philosophy:<br>&gt; &gt;<br>&gt; &gt; If the maintainer of the module is sloppy enough as to not be able to<br>&gt; &gt; provide proper releases, despite the existence of a good release<br>
&gt; &gt; mechanism, then I have little reason to trust that module developer&#39;s code.<br>&gt; &gt;<br>&gt; &gt; i.e, I think people simply should not use these modules.<br>&gt;<br>&gt; But then, these modules should be filtered out of the modules list on<br>
&gt; <a href="http://drupal.org" target="_blank">drupal.org</a>, unless one ticks an &quot;include unreleased modules&quot; checkbox.<br>&gt; That would help greatly in building a module set.<br>&gt;<br>&gt; &nbsp; &nbsp; &nbsp; &nbsp; Xav<br>
&gt;<br>&gt;<br>&gt;<br></div></div></blockquote></div><br>