[development] RFC: drupal as a moving target
catch
catch56 at googlemail.com
Mon Apr 28 12:18:23 UTC 2008
The one change I think we might see this time, and which I'd support, is a
much harder code freeze. We have the potential for SimpleTest coverage and
an extended development cycle, leading to a two months instead of seven for
code freeze this release - which will be a first if it happens. With a
longer code thaw, there should be less of a rush to squeeze patches in
during code freeze, and with SimpleTests we should know much quicker if
stuff is broken (and stop it being broken at all), meaning less time spent
bug hunting during the beta/RC period too. Core being pretty much stable for
two months prior to official release means there'd be more incentive for
contrib maintainers to port modules early, in the relatively safe knowledge
that no big patches will land during that time frame.
The other main issue is CCK and Views are dependencies for a very large
number of contrib modules, and they're under-going major rewrites - so
there's a knock-on effect in terms of sheer numbers of modules being ported.
While this makes raw numbers of contrib upgrades seem slower, as with 4.7.x
- 5.x they're also going to render a lot of modules, and code within
modules, obsolete. Every major Drupal release, despite there being more
modules in total, there's also be a centralisation of code. 4.7-5.x saw the
near disappearance of 'node type' providing modules, a lot of other areas
are increasingly dependent on central APIs for heavy lifting as well (drag
and drop in 6.x for one example) as opposed to maintaining their own
systems. The issue isn't whether APIs break, it's whether we can continue to
make a lot of modules (and code inside modules) unnecessary with those APIs
- so the majority of contrib gets smaller, lighter and easy to upgrade. Of
course one huge API change from D6 to 7/8 might be fields and/or views in
core. I think that'll make the upgrade process quicker rather than slower
for those releases, despite breaking a whole bunch of APIs in the process.
Now this might be the sort of thing you're thinking of when you talk about
trying to move to a more mature, stable API, but otherwise I don't see how
it's much different to http://drupal.org/node/132496
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080428/4a8687f1/attachment.htm
More information about the development
mailing list