[development] RFC: Candidate 'premium' modules
Jose A. Reyero
jareyero at wanadoo.es
Tue May 16 12:11:26 UTC 2006
> Premium modules are those that are:
> a) release-critical - A new version of Drupal cannot be released
> unless these are up-to-date.
> b) quality controlled - these will be 'core modules' in all but name.
> c) well maintained - HEAD, current release and previous release should
> all be maintained preferably by a number of maintainers.
I don't think having some classification of modules would be bad, but I
strongly disagree about delaying Drupal core releases waiting for
non-core modules to be completed.
It's actually the other way around, sometimes we need a finished stable
core to have the modules updated -also because we don't have a module
versioning system which can handle module versions besides the version
numbers in Drupal core.
So, in my case I've been holding back the module release until I'm sure
I can tag it 4.7 and it wont have to be updated 2 days after that to fix
some pending critical bugs...
I don't think it should be a real problem if you have to wait for a few
weeks to have all the modules you need updated. There may be other
people who can use that released core with other modules, and why should
they wait for a module they don't need?
The way to handle module collections is -again, I've talked about this
before- distributions. So, I.e. someone can set up an eCommerce
distribution which will be based on this of that version of core, or
maybe a 'multilingual Drupal' distribution...
But about modules and development either they are core or not. And
that's all we need to know for a Drupal core release. It would be even
better if the core -and the modules it has to wait for- was smaller, so
we could update the other contrib modules before.
More information about the development