RE: [development] no 4-7-0 branch for core yet?
-----Original Message----- From: development-bounces@drupal.org
A time based release cycle has merits.
timeboxing can -needless to say: when done correctly- be a very good way of running a project where needed functionality and available manpower outnumber the due date. it might be that with the grow of the Drupal community and installed base the first two constraints are indeed less scarce resources. switching from the current ("done when its done") way to a "done when its time way", just because the current progress is not up to the expectations of the larger part of the community, might be an unwise decision. note, i am in favor of having two releases per year, it makes the progress predictable, customers do understand the upgrade costs and lifecycle management (support of older versions) can be taken care of in a good way. however, before switching to this development model (only one can decide) everybody needs to understand the impact of it. before people start to complain, best to read http://en.wikipedia.org/wiki/DSDM#Prerequisites_for_using_DSDM
Boerland, Bert wrote:
however, before switching to this development model (only one can decide) everybody needs to understand the impact of it. before people start to complain, best to read http://en.wikipedia.org/wiki/DSDM#Prerequisites_for_using_DSDM
from the linked article: "The second important prerequisite for DSDM projects is the decomposability of the project. The possibility of decomposition into smaller parts enables the iterative and incremental properties of DSDM. It is even possible to create several smaller projects working according to DSDM principles." I think that the working groups site (focused around DEPs) that was proposed in Vancouver will help with this quality. If there is a working group centered around a feature, subsystem, or usability issue, the time boxed release schedule can be a guiding force for the group's development cycle too. -Robert
however, before switching to this development model (only one can decide) everybody needs to understand the impact of it. before people start to complain, best to read http://en.wikipedia.org/wiki/ DSDM#Prerequisites_for_using_DSDM
I don't think we have anything to loose. At any point in time we can choose to switch development model. If we fail to make the deadline, we're back (or we can switch back) to our current strategy. -- Dries Buytaert :: http://www.buytaert.net/
Boerland, Bert wrote:
-----Original Message----- From: development-bounces@drupal.org
A time based release cycle has merits.
The Subversion project has been through this argument, it might be profitable to read their policy: http://subversion.tigris.org/roadmap.html They also have a very clear compatibility statement which Drupal could benefit from: API compatibility through all minor releases: http://subversion.tigris.org/hacking.html#release-numbering This doesn't stop new interfaces being added and old ones deprecated but it does mean the deprecated interfaces will exist until the next major release. -- Martin Tomes echo 'martin at tomes x org x uk'\ | sed -e 's/ x /\./g' -e 's/ at /@/' Visit http://www.subversionary.org/
Martin Tomes wrote:
Boerland, Bert wrote:
-----Original Message----- From: development-bounces@drupal.org
A time based release cycle has merits.
The Subversion project has been through this argument, it might be profitable to read their policy:
http://subversion.tigris.org/roadmap.html
They also have a very clear compatibility statement which Drupal could benefit from: API compatibility through all minor releases:
http://subversion.tigris.org/hacking.html#release-numbering
This doesn't stop new interfaces being added and old ones deprecated but it does mean the deprecated interfaces will exist until the next major release.
There is no way I will ever be in favour of backwards compatibility in Drupal. We keep our apis stable throughout our minor release numbers and that's it. Everybody can update some php files once or twice a yeah. And if they don't feel its worth it: Nobody has to upgrade either. Cheers, Gerhard
participants (5)
-
Boerland, Bert -
Dries Buytaert -
Gerhard Killesreiter -
Martin Tomes -
Robert Douglass