Zend Framework 0.9 beta feature-freeze

[Bill Karwin from Zend]

Hello to the Zend Framework community,

In a couple of days, the Zend Framework project reaches the most
important milestone in its development.  On Thursday March 15, 9:00pm
PDT, we will declare a code-freeze for the first Beta Release of Zend
Framework.  After a day or so of integration testing, we will release
Zend Framework 0.9.0 Beta.

This release is different from earlier Preview Releases of Zend
Framework.  The difference is that the project is also feature-complete,
with respect to Zend Framework 1.0.

Of course after 1.0, we will keep working on the Framework, and add
features.  So don't worry that ZF doesn't have some features yet.  There
will be future versions of Zend Framework, and we will continue to
engineer great PHP 5 solutions, with full documentation and high
standards for testing and overall quality.  I just defined release
milestones in our issue tracker for ZF 1.1, 1.2, and 1.3, so we can
schedule work for those future releases.

The nature of a Beta is that the API is stable and matches what it will
be in the subsequent GA release.  I have declared a policy that there
should be no new features during the Beta.  Changes should be limited to
bug-fixes in current features.  Bug-fixes that require API changes must
be approved (approval will be given conservatively!).

I do encourage improvements to documentation and unit tests during the
Beta.  These do not destabilize the API of the Zend Framework
components; tests and docs support the components.  In fact, the Beta is
a good time to focus on tests and docs.  We feel less pressure to write
new code, and the tests and docs can help us uncover bugs in the
existing features.

The schedule we defined for the release of 1.0 includes a stable release
by the end of March 2007.  We will have a stable release in March, in
the form of Framework 0.9 Beta Release.  I'm sure we will fix enough
bugs in 0.9.0 to justify a 0.9.1 Beta Refresh by the end of this month.

Why do we have such a strict need to meet this schedule?  

We are currently in a situation where we already have a large number of
users of Zend Framework.  Unfortunately (or fortunately) quite a lot of
them are already using Zend Framework in production.  When we talk to
users (and not only contributors) the number one request made by all of
them is to have a stable release which also stabilizes APIs.  Their #1
priority is not lack of features.  We therefore truly believe that the
best thing we can do for users of Zend Framework is to stabilize the
current feature set and work towards a shippable and supportable
version.  That is far more valuable to the majority of them than any
additional features.

To make Zend Framework a success, we define the single most important
feature is to make a production-ready release 1.0.  As the saying goes,
"shipping is a feature!"  The priority on schedule is higher than the
priority on any new features.

The plan is that after the Beta Refresh, we will create a branch in
subversion, on which the Zend Framework 1.0 GA release is based.  After
that, we can continue to add features in the trunk of subversion,
without impacting the stability of the 1.0 branch.

But even in the trunk, we will emphasize backward-compatibility wherever
possible, so that when we release Zend Framework 1.1, 1.2, 1.3, and
other future enhancements, users of Zend Framework will have an easy
transition and can adopt new features.  One of the quality goals of this
project is that an application using Zend Framework 1.0 does not have to
be totally rewritten to use Zend Framework 2.0.  After 1.0, any change
to the API must be approved by a Change Control process, and accompanied
with detailed documentation to describe how to migrate an existing
application to the new API change.

Also note that starting with the Zend Framework 0.9.1 Beta Refresh, we
plan to leave the incubator directory out of the released product.  The
incubator will still be available by subversion checkouts and in the
nightly snapshot, but the stable product releases will be based on the
"core" library, tests, and docs only.

Regards,
Bill Karwin

[Bill Karwin from Zend]

Well, that's why I stated it the way I did.  Making some minor API
changes between 1.0 and 2.0 is expected, but if a developer has to learn
a completely new API and change every line of his code that uses ZF,
that would not be good.

Another form of preserving backward-compatibility is to create implement
new classes and methods that coexist with old ones, without affecting
apps that use the old code. That's why you see methods like
mysqli_real_escape_string() or execute2().  I really dislike seeing
things like that, but they are sometimes necessary to preserve backward
compatibility.

So, in short -- yes, seriously, backward-compatibility is important.
Zend Framework will achieve more success and more IT departments will
use it, if and only if the project shows some commitment to keeping API
contracts.

Regards,
Bill Karwin

> -----Original Message-----
> From: SantosJ [mailto:jacobsantos@...]
> Sent: Tuesday, March 13, 2007 8:12 PM
> To: Bill Karwin
> Subject: Re: [fw-general] Zend Framework 0.9 beta feature-freeze
>
> Oops, that was a lot of stuff and I didn't read it all. I don't like
> this part, "...an application using Zend Framework 1.0 does not have
to
> be totally rewritten to use Zend Framework 2.0."
>
> Seriously? I think it might be a good idea to allow such a refresh so
that
> refactoring can occur at the major release level. I don't think many
would
> mind updating for a major (2.0, 3.0, etc) release, but would on a
minor
> (1.1, 1.2, 2.1, etc). At least I don't mind or won't mind whenever the
> case might be.
>
> Jacob Santos
>
> > But even in the trunk, we will emphasize backward-compatibility
wherever
> > possible, so that when we release Zend Framework 1.1, 1.2, 1.3, and
> > other future enhancements, users of Zend Framework will have an easy
> > transition and can adopt new features.  One of the quality goals of
this
> > project is that an application using Zend Framework 1.0 does not
have to
> > be totally rewritten to use Zend Framework 2.0.  After 1.0, any
change
> > to the API must be approved by a Change Control process, and
accompanied
> > with detailed documentation to describe how to migrate an existing
> > application to the new API change.
> >