[development] no 4-7-0 branch for core yet?

[Walt Daniels]

Agree!!!!
Even after 4.7 drops, the contribs that I depend on won't be ready for at
least a while. Currently they are very badly marked as to which version they
work with. The release policy must take the contribs into account. You can't
turn the releases unless the contribs can keep up.

There are lots of remarks about things that work with PHP 4 or 5, but none
about things that work with MySQL 4 or 5. Dreamhost just went to MySQL5 and
I am stuck badly. So changes in these two which have no reason to folllow
the Drupal schedule have to be factored into possible Drupal schedules. I
have a tight deadline of getting off my current ISP (which dies March 29)
and onto Dreamhost. Drupal 4.6 does not work with MySQL 5 and 4.7 + its
contribs is not likely to be ready for production.

> -----Original Message-----
> From: development-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] On Behalf Of Chris Johnson
> Sent: Monday, February 20, 2006 3:09 PM
> To: development at drupal.org
> Subject: Re: [development] no 4-7-0 branch for core yet?
> 
> Morbus Iff wrote:
> >> between 4.6 and 4.7 should really be major release number changes, 
> >> e.g
> >> 4.6 -> 5.0, not point releases.
> > 
> > I disagree. If I can simplify the last six months of work:
> > 
> >   FormAPI or, as I prefer, FAPI.
> >   Security/validation related to FAPI
> > 
> > This is a framework/API "developer feature", and not something that 
> > the end-user will ever care to appreciate. Taking FAPI out of the 
> > equation, I don't really see the number of *important* 
> features that 
> > would make justify a 5.0 release.
> > 
> 
> Whether the changes are to the end user is only a part of the 
> equation.  The revision number of the software should provide 
> a general guideline to all audiences as to how much of a 
> change a particular release contains.  End users who can 
> "see" the change are only one member of  the set of all audiences.
> 
> Members of those audiences might include:
> 1.  Drupal core developers
> 2.  Drupal module developers
> 3.  Drupal theme developers
> 4.  Consultants
> 5.  Site developers
> 6.  Site administrators
> 7.  IT administrators
> 8.  Site owner entity management (e.g. NGO boards or 
> for-profit management) 9.  End users 10. Etc.
> 
> All of these people need to know something has changed.  One 
> might argue that End Users themselves have the least need to 
> be notified, since they will either "see" the difference -- 
> or they won't.
> 
> Morbus' argument that most of the 4.7 changes are "developer 
> features" (and therefore the revision number need not reflect 
> their scope) leaves out the other audiences.
> 
> Consultants need to know how big a change it might mean to 
> their current clients.  Site developers need to know which 
> version to target for a site that has to go live in 4 weeks, 
> and they need to know how much effort it's going to take to 
> upgrade from 4.6 to 4.7 to correctly make that decision.
> 
> IT administrators and Site Owners need to know that 4.6 to 
> 4.7 is a big change so that they can manage their resources, 
> schedule their upgrades and plan their next 6 to 12 months of 
> system, network, site and related software activity.
> 
> Drupal sites don't exist in a vacuum, especially not anymore. 
>  Managing a Drupal-based website often means more than 
> worrying about the Drupal version.
> 
> Bryght is plugged in technically and won't have a problem.  
> But it's just as possible that other organizations have made 
> similar large commitments to using Drupal, and they may not 
> be as plugged in.  They need a BIG Red Sign in the form of a 
> major release number to let them know that 4.7 is 
> dramatically different "under the hood" from 4.6, and that 
> upgrading is going to take lots of manpower.
> 
> The Form API change should have made 4.7 be named 5.0.  It's 
> too late to rename it, but the revision numbers should be in 
> accord with that kind thinking, contrary to what Morbus argues.
> 
> ..chris
> 
> 
> 
>