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

[mark burdett]

I am running drupal 4.6 on mysql 5, with standard configs. I'm
wondering if people having this trouble aren't doing something to
my.cnf or during compilation?

--mark

On 2/20/06, Walt Daniels <wdlists at optonline.net> wrote:
> 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
> >
> >
> >
> >
>
>


--
mark burdett
mark at goodstorm.com
+1 (415) 341-2815 [mobile]
+1 (415) 223-0305 [office]
http://www.goodstorm.com/
835 Terry Francois St
San Francisco CA 94158-2209