Proposal: Don't implement BC requirement until ZF 2.1

[akrabat]

Hi,

One thing that I think hurt ZF 1 was that we froze the API and introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people really started using ZF and we learnt about all the use-cases that hadn't been thought of. I'm assuming that ZF 2's usage will go the same way and we won't get any serious adoption and testing until ZF 2.0 is released, regardless of how many betas and RCs we put out.

In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,

Thoughts?


Rob...
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Bittarman]

I'd like to second this straight away.

It allows real-world usage to give decent feedback on what needs changing, before we start pouring concrete around the api, setting up an exclusion zone, and treating it like a nuclear disaster!

Ryan

On 15 Jun 2011, at 22:03, Rob Allen <[hidden email]> wrote:

> Hi,
>
> One thing that I think hurt ZF 1 was that we froze the API and introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people really started using ZF and we learnt about all the use-cases that hadn't been thought of. I'm assuming that ZF 2's usage will go the same way and we won't get any serious adoption and testing until ZF 2.0 is released, regardless of how many betas and RCs we put out.
>
> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,
>
> Thoughts?
>
>
> Rob...
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Anthony Shireman]

I'll third the motion. After refactoring an application to work with ZF2.0,
it really shouldn't be too bad if there are changes. And even if there are
changes it should just make everything better and well worth the little bit
of effort.



On Wed, Jun 15, 2011 at 2:41 PM, Ryan Mauger <[hidden email]> wrote:

> I'd like to second this straight away.
>
> It allows real-world usage to give decent feedback on what needs changing,
> before we start pouring concrete around the api, setting up an exclusion
> zone, and treating it like a nuclear disaster!
>
> Ryan
>
> On 15 Jun 2011, at 22:03, Rob Allen <[hidden email]> wrote:
>
> > Hi,
> >
> > One thing that I think hurt ZF 1 was that we froze the API and introduced
> the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people
> really started using ZF and we learnt about all the use-cases that hadn't
> been thought of. I'm assuming that ZF 2's usage will go the same way and we
> won't get any serious adoption and testing until ZF 2.0 is released,
> regardless of how many betas and RCs we put out.
> >
> > In the light of this expectation I'd like to propose that we allow BC
> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
> significantly more people are using it,
> >
> > Thoughts?
> >
> >
> > Rob...
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[H Glenn Hatfield]

On Wed, Jun 15, 2011 at 3:03 PM, Rob Allen <[hidden email]> wrote:

> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,


+.8

I really like this idea. What do you do with features added after 2.0?
Does a feature added in 2.1.4 have to never break BC or is there a
sliding window where it could break BC until 2.2 or perhaps 2.3?


H

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[merrix]

With PEAR at least you shouldn't be breaking BC on whole minor
versions ie 2.0, 2.1, etc...

Sent from my iPhone

On Jun 15, 2011, at 3:04 PM, H Hatfield <[hidden email]> wrote:

> On Wed, Jun 15, 2011 at 3:03 PM, Rob Allen <[hidden email]> wrote:
>
>> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,
>
>
> +.8
>
> I really like this idea. What do you do with features added after 2.0?
> Does a feature added in 2.1.4 have to never break BC or is there a
> sliding window where it could break BC until 2.2 or perhaps 2.3?
>
>
> H
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Kevin McArthur-2]

Why are you presuming a 2.0 release before it is ready?

Lets be a little more like OpenSSL with the version numbers on this series?

--

K

On 11-06-15 02:03 PM, Rob Allen wrote:

> Hi,
>
> One thing that I think hurt ZF 1 was that we froze the API and introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people really started using ZF and we learnt about all the use-cases that hadn't been thought of. I'm assuming that ZF 2's usage will go the same way and we won't get any serious adoption and testing until ZF 2.0 is released, regardless of how many betas and RCs we put out.
>
> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,
>
> Thoughts?
>
>
> Rob...

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Tomáš Fejfar]

We might need a psychologist here :) * <http://www.tomasfejfar.cz>* What
version scheme would make people adopt the desired "pre-release" version and
not wait until some "final release" :)

On Thu, Jun 16, 2011 at 12:07 AM, Kevin McArthur <[hidden email]> wrote:

> OpenSSL

[robzienert]

+1 on the condition that we make best efforts to communicate the plan and
reasoning ahead of time and at 2.0 release. Regardless of how much sense
this makes to us, a decision like this could land ZF some undue criticisms
from the blogosphere.

- Robz

On Wed, Jun 15, 2011 at 5:03 PM, Rob Allen <[hidden email]> wrote:

> Hi,
>
> One thing that I think hurt ZF 1 was that we froze the API and introduced
> the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people
> really started using ZF and we learnt about all the use-cases that hadn't
> been thought of. I'm assuming that ZF 2's usage will go the same way and we
> won't get any serious adoption and testing until ZF 2.0 is released,
> regardless of how many betas and RCs we put out.
>
> In the light of this expectation I'd like to propose that we allow BC
> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
> significantly more people are using it,
>
> Thoughts?
>
>
> Rob...
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[till-2]

On Wed, Jun 15, 2011 at 11:03 PM, Rob Allen <[hidden email]> wrote:
> Hi,
>
> One thing that I think hurt ZF 1 was that we froze the API and introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people really started using ZF and we learnt about all the use-cases that hadn't been thought of. I'm assuming that ZF 2's usage will go the same way and we won't get any serious adoption and testing until ZF 2.0 is released, regardless of how many betas and RCs we put out.
>
> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,
>
> Thoughts?

-1

I'm not sure when you started using ZF but I've actually been there
since the early 0.x days. Have you ever updated the framework code
before it reached 1.0? It required a lot of work, despite the best
efforts of Matthew and co to list BC changes.

I'm strongly against breaking BC unless it's a major release. It's one
of the reasons why I use ZF and some other framework which requires me
to re-write code constantly between minor releases.

There's been some ups and downs, but generally updating the code base
was really simple since the framework became 1.0. I don't want this to
change.

This kind of thing requires that people think before they implement
components. It's gotten a lot better with code review of new
components and so on. Keeping BC is not the problem, not thinking
about the code that is put into the framework is.

If you want people to test ZF2, there needs to be a quickstart and
some documentation for a basic application. But since the MVC layer is
a moving target, there's nothing yet. Also, you need a place to build
the API docs and so on. I'm not aware of any of those things yet.

Till

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Tomáš Fejfar]

Point is that it's more of a psychology game... to make people use ZF2 more.
It's documented "hurt person" problem - when person is hurt on a deserted
road, first bycommer helps him. But he may lay for minutes on a busy road,
because from certain "density" everyone assumes "someone else will help".
Same would be with ZF2beta - everyone knows it'S needed to have many users
using it for polishing the API, but a lot of people will think that "someone
else will try it and i will wait for stable".

On Thu, Jun 16, 2011 at 11:20 PM, till <[hidden email]> wrote:

> On Wed, Jun 15, 2011 at 11:03 PM, Rob Allen <[hidden email]> wrote:
> > Hi,
> >
> > One thing that I think hurt ZF 1 was that we froze the API and introduced
> the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people
> really started using ZF and we learnt about all the use-cases that hadn't
> been thought of. I'm assuming that ZF 2's usage will go the same way and we
> won't get any serious adoption and testing until ZF 2.0 is released,
> regardless of how many betas and RCs we put out.
> >
> > In the light of this expectation I'd like to propose that we allow BC
> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
> significantly more people are using it,
> >
> > Thoughts?
>
> -1
>
> I'm not sure when you started using ZF but I've actually been there
> since the early 0.x days. Have you ever updated the framework code
> before it reached 1.0? It required a lot of work, despite the best
> efforts of Matthew and co to list BC changes.
>
> I'm strongly against breaking BC unless it's a major release. It's one
> of the reasons why I use ZF and some other framework which requires me
> to re-write code constantly between minor releases.
>
> There's been some ups and downs, but generally updating the code base
> was really simple since the framework became 1.0. I don't want this to
> change.
>
> This kind of thing requires that people think before they implement
> components. It's gotten a lot better with code review of new
> components and so on. Keeping BC is not the problem, not thinking
> about the code that is put into the framework is.
>
> If you want people to test ZF2, there needs to be a quickstart and
> some documentation for a basic application. But since the MVC layer is
> a moving target, there's nothing yet. Also, you need a place to build
> the API docs and so on. I'm not aware of any of those things yet.
>
> Till
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[till-2]

That's a chicken egg problem?

As I said, I think with tutorials, people will try it out.

I talked to Ralph last night on IRC and he mentioned that it's mostly
the DIC right now that's available for testing. So not (!) to belittle
anyone's effort, but how do you guys expect people to try this out?
I'm seriously asking. If you're using Symfony2, why would I test ZF2's
DIC? Or why would I use this instead of a simple DIC like pimple. What
I'm getting at, this is just not enough to get people to try it (yet).

Improve this page and they will come:
http://framework.zend.com/wiki/display/ZFDEV2/Documentation

;-)

Anyway, having said this. I'll go ahead and fork the bastard ;-) and
play with it and see if I can contribute more docs in a way.

Till

2011/6/17 Tomáš Fejfar <[hidden email]>:

> Point is that it's more of a psychology game... to make people use ZF2 more.
> It's documented "hurt person" problem - when person is hurt on a deserted
> road, first bycommer helps him. But he may lay for minutes on a busy road,
> because from certain "density" everyone assumes "someone else will help".
> Same would be with ZF2beta - everyone knows it'S needed to have many users
> using it for polishing the API, but a lot of people will think that "someone
> else will try it and i will wait for stable".
>
> On Thu, Jun 16, 2011 at 11:20 PM, till <[hidden email]> wrote:
>
>> On Wed, Jun 15, 2011 at 11:03 PM, Rob Allen <[hidden email]> wrote:
>> > Hi,
>> >
>> > One thing that I think hurt ZF 1 was that we froze the API and introduced
>> the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people
>> really started using ZF and we learnt about all the use-cases that hadn't
>> been thought of. I'm assuming that ZF 2's usage will go the same way and we
>> won't get any serious adoption and testing until ZF 2.0 is released,
>> regardless of how many betas and RCs we put out.
>> >
>> > In the light of this expectation I'd like to propose that we allow BC
>> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
>> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
>> significantly more people are using it,
>> >
>> > Thoughts?
>>
>> -1
>>
>> I'm not sure when you started using ZF but I've actually been there
>> since the early 0.x days. Have you ever updated the framework code
>> before it reached 1.0? It required a lot of work, despite the best
>> efforts of Matthew and co to list BC changes.
>>
>> I'm strongly against breaking BC unless it's a major release. It's one
>> of the reasons why I use ZF and some other framework which requires me
>> to re-write code constantly between minor releases.
>>
>> There's been some ups and downs, but generally updating the code base
>> was really simple since the framework became 1.0. I don't want this to
>> change.
>>
>> This kind of thing requires that people think before they implement
>> components. It's gotten a lot better with code review of new
>> components and so on. Keeping BC is not the problem, not thinking
>> about the code that is put into the framework is.
>>
>> If you want people to test ZF2, there needs to be a quickstart and
>> some documentation for a basic application. But since the MVC layer is
>> a moving target, there's nothing yet. Also, you need a place to build
>> the API docs and so on. I'm not aware of any of those things yet.
>>
>> Till
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[weierophinney]

-- till <[hidden email]> wrote
(on Friday, 17 June 2011, 02:28 PM +0200):
> That's a chicken egg problem?

It is, and it isn't. It's a common problem with betas and RCs for PHP
itself, actually -- folks don't try them until a GA release is out, and
by then, it's too late to report issues with
interfaces/functionality/etc.

I think what Rob is getting at is that we perhaps treat the 2.0.X series
as a kind of extended beta.

> As I said, I think with tutorials, people will try it out.

Potentially. That worked for ZF1, certainly -- we had heavy adoption
even before stable. I think the bigger issue right now is that a lot of
folks have indicated they're waiting for a stable release of ZF2 before
they try anything -- and, as noted, that's too late to report issues
with interfaces or the API.

> I talked to Ralph last night on IRC and he mentioned that it's mostly
> the DIC right now that's available for testing. So not (!) to belittle
> anyone's effort, but how do you guys expect people to try this out?
> I'm seriously asking. If you're using Symfony2, why would I test ZF2's
> DIC? Or why would I use this instead of a simple DIC like pimple. What
> I'm getting at, this is just not enough to get people to try it (yet).

It's enough for early adopters to test this component and see if they
can incorporate it into workflows. It can certainly be used as a
replacement "Container" within Zend_Application_Bootstrap already, which
allows folks to test if that approach works.

Yes, I agree: we need bigger features (working MVC) to get more testers.

> Improve this page and they will come:
> http://framework.zend.com/wiki/display/ZFDEV2/Documentation

That's hardly fair. Most docs are in the distribution already in DocBook
format -- we're simply placing isolated docs there so folks don't need
to build them.

> ;-)
>
> Anyway, having said this. I'll go ahead and fork the bastard ;-) and
> play with it and see if I can contribute more docs in a way.

Please do. :)

> 2011/6/17 Tomáš Fejfar <[hidden email]>:
> > Point is that it's more of a psychology game... to make people use ZF2 more.
> > It's documented "hurt person" problem - when person is hurt on a deserted
> > road, first bycommer helps him. But he may lay for minutes on a busy road,
> > because from certain "density" everyone assumes "someone else will help".
> > Same would be with ZF2beta - everyone knows it'S needed to have many users
> > using it for polishing the API, but a lot of people will think that "someone
> > else will try it and i will wait for stable".
> >
> > On Thu, Jun 16, 2011 at 11:20 PM, till <[hidden email]> wrote:
> >
> >> On Wed, Jun 15, 2011 at 11:03 PM, Rob Allen <[hidden email]> wrote:
> >> > Hi,
> >> >
> >> > One thing that I think hurt ZF 1 was that we froze the API and introduced
> >> the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people
> >> really started using ZF and we learnt about all the use-cases that hadn't
> >> been thought of. I'm assuming that ZF 2's usage will go the same way and we
> >> won't get any serious adoption and testing until ZF 2.0 is released,
> >> regardless of how many betas and RCs we put out.
> >> >
> >> > In the light of this expectation I'd like to propose that we allow BC
> >> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
> >> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
> >> significantly more people are using it,
> >> >
> >> > Thoughts?
> >>
> >> -1
> >>
> >> I'm not sure when you started using ZF but I've actually been there
> >> since the early 0.x days. Have you ever updated the framework code
> >> before it reached 1.0? It required a lot of work, despite the best
> >> efforts of Matthew and co to list BC changes.
> >>
> >> I'm strongly against breaking BC unless it's a major release. It's one
> >> of the reasons why I use ZF and some other framework which requires me
> >> to re-write code constantly between minor releases.
> >>
> >> There's been some ups and downs, but generally updating the code base
> >> was really simple since the framework became 1.0. I don't want this to
> >> change.
> >>
> >> This kind of thing requires that people think before they implement
> >> components. It's gotten a lot better with code review of new
> >> components and so on. Keeping BC is not the problem, not thinking
> >> about the code that is put into the framework is.
> >>
> >> If you want people to test ZF2, there needs to be a quickstart and
> >> some documentation for a basic application. But since the MVC layer is
> >> a moving target, there's nothing yet. Also, you need a place to build
> >> the API docs and so on. I'm not aware of any of those things yet.
> >>
> >> Till
> >>
> >> --
> >> List: [hidden email]
> >> Info: http://framework.zend.com/archives
> >> Unsubscribe: [hidden email]
> >>
> >>
> >>
> >
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[till-2]

On Fri, Jun 17, 2011 at 5:56 PM, Matthew Weier O'Phinney
<[hidden email]> wrote:

> -- till <[hidden email]> wrote
> (on Friday, 17 June 2011, 02:28 PM +0200):
>> That's a chicken egg problem?
>
> It is, and it isn't. It's a common problem with betas and RCs for PHP
> itself, actually -- folks don't try them until a GA release is out, and
> by then, it's too late to report issues with
> interfaces/functionality/etc.
>
> I think what Rob is getting at is that we perhaps treat the 2.0.X series
> as a kind of extended beta.
>
>> As I said, I think with tutorials, people will try it out.
>
> Potentially. That worked for ZF1, certainly -- we had heavy adoption
> even before stable. I think the bigger issue right now is that a lot of
> folks have indicated they're waiting for a stable release of ZF2 before
> they try anything -- and, as noted, that's too late to report issues
> with interfaces or the API.
>
>> I talked to Ralph last night on IRC and he mentioned that it's mostly
>> the DIC right now that's available for testing. So not (!) to belittle
>> anyone's effort, but how do you guys expect people to try this out?
>> I'm seriously asking. If you're using Symfony2, why would I test ZF2's
>> DIC? Or why would I use this instead of a simple DIC like pimple. What
>> I'm getting at, this is just not enough to get people to try it (yet).
>
> It's enough for early adopters to test this component and see if they
> can incorporate it into workflows. It can certainly be used as a
> replacement "Container" within Zend_Application_Bootstrap already, which
> allows folks to test if that approach works.
>
> Yes, I agree: we need bigger features (working MVC) to get more testers.
>
>> Improve this page and they will come:
>> http://framework.zend.com/wiki/display/ZFDEV2/Documentation
>
> That's hardly fair. Most docs are in the distribution already in DocBook
> format -- we're simply placing isolated docs there so folks don't need
> to build them.

Didn't know that - so I have to build the docbook to get
documentation, or is that getting build somewhere already? If the
latter is the case, then the link should be added to the wiki page.

Till

>> ;-)
>>
>> Anyway, having said this. I'll go ahead and fork the bastard ;-) and
>> play with it and see if I can contribute more docs in a way.
>
> Please do. :)
>
>
>> 2011/6/17 Tomáš Fejfar <[hidden email]>:
>> > Point is that it's more of a psychology game... to make people use ZF2 more.
>> > It's documented "hurt person" problem - when person is hurt on a deserted
>> > road, first bycommer helps him. But he may lay for minutes on a busy road,
>> > because from certain "density" everyone assumes "someone else will help".
>> > Same would be with ZF2beta - everyone knows it'S needed to have many users
>> > using it for polishing the API, but a lot of people will think that "someone
>> > else will try it and i will wait for stable".
>> >
>> > On Thu, Jun 16, 2011 at 11:20 PM, till <[hidden email]> wrote:
>> >
>> >> On Wed, Jun 15, 2011 at 11:03 PM, Rob Allen <[hidden email]> wrote:
>> >> > Hi,
>> >> >
>> >> > One thing that I think hurt ZF 1 was that we froze the API and introduced
>> >> the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people
>> >> really started using ZF and we learnt about all the use-cases that hadn't
>> >> been thought of. I'm assuming that ZF 2's usage will go the same way and we
>> >> won't get any serious adoption and testing until ZF 2.0 is released,
>> >> regardless of how many betas and RCs we put out.
>> >> >
>> >> > In the light of this expectation I'd like to propose that we allow BC
>> >> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
>> >> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
>> >> significantly more people are using it,
>> >> >
>> >> > Thoughts?
>> >>
>> >> -1
>> >>
>> >> I'm not sure when you started using ZF but I've actually been there
>> >> since the early 0.x days. Have you ever updated the framework code
>> >> before it reached 1.0? It required a lot of work, despite the best
>> >> efforts of Matthew and co to list BC changes.
>> >>
>> >> I'm strongly against breaking BC unless it's a major release. It's one
>> >> of the reasons why I use ZF and some other framework which requires me
>> >> to re-write code constantly between minor releases.
>> >>
>> >> There's been some ups and downs, but generally updating the code base
>> >> was really simple since the framework became 1.0. I don't want this to
>> >> change.
>> >>
>> >> This kind of thing requires that people think before they implement
>> >> components. It's gotten a lot better with code review of new
>> >> components and so on. Keeping BC is not the problem, not thinking
>> >> about the code that is put into the framework is.
>> >>
>> >> If you want people to test ZF2, there needs to be a quickstart and
>> >> some documentation for a basic application. But since the MVC layer is
>> >> a moving target, there's nothing yet. Also, you need a place to build
>> >> the API docs and so on. I'm not aware of any of those things yet.
>> >>
>> >> Till
>> >>
>> >> --
>> >> List: [hidden email]
>> >> Info: http://framework.zend.com/archives
>> >> Unsubscribe: [hidden email]
>> >>
>> >>
>> >>
>> >
>>
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead            | [hidden email]
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[akrabat]

On 17 Jun 2011, at 16:56, Matthew Weier O'Phinney wrote:

> -- till <[hidden email]> wrote
> (on Friday, 17 June 2011, 02:28 PM +0200):
>> That's a chicken egg problem?
>
> It is, and it isn't. It's a common problem with betas and RCs for PHP
> itself, actually -- folks don't try them until a GA release is out, and
> by then, it's too late to report issues with
> interfaces/functionality/etc.
>
> I think what Rob is getting at is that we perhaps treat the 2.0.X series
> as a kind of extended beta.

Exactly. 2.1 would definitely be API frozen. I would contend that it was only after 1.0 that we got most of our users, even though there were a fair few using it beforehand. I suppose a certain amount depends on how long the Beta period is after we have a "complete" ZF2.

I would suggest that introducing a BC break after 2.0 would require more serious consideration than before 2.0, but being able to break BC if we find something that would be significantly better for the long term health of the framework would be handy.


Regards,

Rob...
--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Andries Seutens-4]

Op 19/06/2011 19:55, Rob Allen schreef:

> On 17 Jun 2011, at 16:56, Matthew Weier O'Phinney wrote:
>
>> -- till<[hidden email]>  wrote
>> (on Friday, 17 June 2011, 02:28 PM +0200):
>>> That's a chicken egg problem?
>> It is, and it isn't. It's a common problem with betas and RCs for PHP
>> itself, actually -- folks don't try them until a GA release is out, and
>> by then, it's too late to report issues with
>> interfaces/functionality/etc.
>>
>> I think what Rob is getting at is that we perhaps treat the 2.0.X series
>> as a kind of extended beta.
> Exactly. 2.1 would definitely be API frozen. I would contend that it was only after 1.0 that we got most of our users, even though there were a fair few using it beforehand. I suppose a certain amount depends on how long the Beta period is after we have a "complete" ZF2.
>
> I would suggest that introducing a BC break after 2.0 would require more serious consideration than before 2.0, but being able to break BC if we find something that would be significantly better for the long term health of the framework would be handy.
>
>
> Regards,
>
> Rob...

Once you tag 2.0, BC breaks should no longer be allowed, unless those BC
breaks are done in a seperate 3.0 branch.
This means that you'll have to live with the consequences of maintaining
3 major versions...

Just my 2 cents.

Andriesss




--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Bradley Holt]

On Wed, Jun 15, 2011 at 5:03 PM, Rob Allen <[hidden email]> wrote:
>
> Hi,
>
> One thing that I think hurt ZF 1 was that we froze the API and introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people really started using ZF and we learnt about all the use-cases that hadn't been thought of. I'm assuming that ZF 2's usage will go the same way and we won't get any serious adoption and testing until ZF 2.0 is released, regardless of how many betas and RCs we put out.
>
> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,
>
> Thoughts?
>

-1 (sorry I'm late to the party)

I would suggest two possible alternatives that may help.

First, Zend Framework could adopt an odd-even release strategy for
minor releases. The Apache HTTP Server does this. Odd numbered minor
releases (e.g. 2.1) are considered beta releases and even numbered
minor releases (e.g. 2.2) are considered general availability (GA)
releases. This would allow BC changes between any odd minor release
and the subsequent even minor release since the previous odd minor
release would have been a beta version.

This approach has the added benefit of working beyond the 2.0 release,
however it does not address the specific concern in the original post
as 2.0 would be a GA release (since it's an even numbered minor
release) under this scheme. I think it's important to mark a minor
release as a development, alpha, beta, or release candidate version if
users can expect BC changes in subsequent releases within the same
major version. This would mean sticking to 2.0b1, 2.0b2, 2.0b3 etc.
beta releases before the 2.0.0 GA release (I wouldn't use RC releases
as this implies that a GA release is imminent and would probably do
more harm than good). I think it's a matter of communication and time.
If we clearly communicate that users are expected download and try out
the beta releases and then make people wait long enough for 2.0.0,
then that should hopefully encourage people to try out the beta
version. In other words, keep pushing out beta releases and don't be
in a rush to get to 2.0 GA.

Second, increase the pace of major releases. Both Chrome and Firefox
have shifted to a more rapid release cycle where major versions are
released as often as every six weeks. This may be a bit fast-paced for
Zend Framework—every 6 months might be more appropriate—but you get
the idea. This would help relieve some of the pressure on needing to
get everything perfect with each major release. I'd rather see major
releases with small BC changes made every six months than one large BC
change made with a major release every four years (ZF 1.0.0 was
released in July of 2007). Of course, this would bring up the issue of
supporting multiple major releases simultaneously, which may be a
problem.

TL;DR:

* Use an odd-even release strategy: odd minor releases are beta
releases, even minor releases are general availability (GA) releases
* Release multiple 2.0b1, 2.0b2, 2.0b3 etc. beta releases (but not RC
releases, as that implies a GA release is imminent) before the 2.0.0
GA release
* Clearly communicate that developers are expected to use the beta releases
* Don't be in a rush to release 2.0.0—make developers wait and use the
beta releases
* Release major versions every six months, rather than ever four
years, relieving the pressure on needing to get each major release
perfect and allowing for more BC change opportunities

Thanks,
Bradley

>
> Rob...
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[Anthony Shireman]

I like the idea of a 2.0b_ series that would allow BC breaks before a 2.0 release/final to allow some usage of the code, get wider feedback, before locking in and keeping BC until the next major release.



Tony Shireman

On Jun 22, 2011, at 3:11 PM, Bradley Holt <[hidden email]> wrote:

> On Wed, Jun 15, 2011 at 5:03 PM, Rob Allen <[hidden email]> wrote:
>>
>> Hi,
>>
>> One thing that I think hurt ZF 1 was that we froze the API and introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when people really started using ZF and we learnt about all the use-cases that hadn't been thought of. I'm assuming that ZF 2's usage will go the same way and we won't get any serious adoption and testing until ZF 2.0 is released, regardless of how many betas and RCs we put out.
>>
>> In the light of this expectation I'd like to propose that we allow BC breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement for 2.1 onwards as it would allow us to fix the mistakes we don't find until significantly more people are using it,
>>
>> Thoughts?
>>
>
> -1 (sorry I'm late to the party)
>
> I would suggest two possible alternatives that may help.
>
> First, Zend Framework could adopt an odd-even release strategy for
> minor releases. The Apache HTTP Server does this. Odd numbered minor
> releases (e.g. 2.1) are considered beta releases and even numbered
> minor releases (e.g. 2.2) are considered general availability (GA)
> releases. This would allow BC changes between any odd minor release
> and the subsequent even minor release since the previous odd minor
> release would have been a beta version.
>
> This approach has the added benefit of working beyond the 2.0 release,
> however it does not address the specific concern in the original post
> as 2.0 would be a GA release (since it's an even numbered minor
> release) under this scheme. I think it's important to mark a minor
> release as a development, alpha, beta, or release candidate version if
> users can expect BC changes in subsequent releases within the same
> major version. This would mean sticking to 2.0b1, 2.0b2, 2.0b3 etc.
> beta releases before the 2.0.0 GA release (I wouldn't use RC releases
> as this implies that a GA release is imminent and would probably do
> more harm than good). I think it's a matter of communication and time.
> If we clearly communicate that users are expected download and try out
> the beta releases and then make people wait long enough for 2.0.0,
> then that should hopefully encourage people to try out the beta
> version. In other words, keep pushing out beta releases and don't be
> in a rush to get to 2.0 GA.
>
> Second, increase the pace of major releases. Both Chrome and Firefox
> have shifted to a more rapid release cycle where major versions are
> released as often as every six weeks. This may be a bit fast-paced for
> Zend Framework—every 6 months might be more appropriate—but you get
> the idea. This would help relieve some of the pressure on needing to
> get everything perfect with each major release. I'd rather see major
> releases with small BC changes made every six months than one large BC
> change made with a major release every four years (ZF 1.0.0 was
> released in July of 2007). Of course, this would bring up the issue of
> supporting multiple major releases simultaneously, which may be a
> problem.
>
> TL;DR:
>
> * Use an odd-even release strategy: odd minor releases are beta
> releases, even minor releases are general availability (GA) releases
> * Release multiple 2.0b1, 2.0b2, 2.0b3 etc. beta releases (but not RC
> releases, as that implies a GA release is imminent) before the 2.0.0
> GA release
> * Clearly communicate that developers are expected to use the beta releases
> * Don't be in a rush to release 2.0.0—make developers wait and use the
> beta releases
> * Release major versions every six months, rather than ever four
> years, relieving the pressure on needing to get each major release
> perfect and allowing for more BC change opportunities
>
> Thanks,
> Bradley
>
>>
>> Rob...
>> --
>> List: [hidden email]
>> Info: http://framework.zend.com/archives
>> Unsubscribe: [hidden email]
>>
>>
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]

[David Muir]

Anthony Shireman wrote

I like the idea of a 2.0b_ series that would allow BC breaks before a 2.0 release/final to allow some usage of the code, get wider feedback, before locking in and keeping BC until the next major release.

I don't think that will work, as a lot of people (myself included) will not port over to ZF2 until the API is frozen. If the API is not frozen until 2.1, then not only will you piss off a bunch of early adopters unaware of the planned possible BC break, but you'll also scare away people who do know about the possible break until 2.1 is out.

I'd suggest keeping BC for the 2 series, and save BC breaks for the 3 series. 3 should not be a complete rewrite of ZF2 like the current cycle, but instead be focused on cleaning up problem areas identified after 2.0 is out. So rather than 3 coming out some time after 2.11.7 ;-), we'd see a 3 release closer to 2.3 or 2.4, with a much easier migration path than the current ZF1 -> ZF2.

As a concession, maybe plan for the BC break to happen at 2.5, with a visible gap in version numbers. Eg: 2.0, 2.1, then 2.5. The gap signals that the changes coming are bigger than normal, and less of a surprise if they include larger BC breaks?

Cheers,
David

[Tomáš Fejfar]

If I understand right the point was that Rob was afraid people won't use
betas enought, and will wail for first stable release - that will reveal
many unforeseen use cases after 2.0.0, without the possibility to change
API. It's not about if we have/how we call betas.

Tom

On Thu, Jun 23, 2011 at 2:28 AM, Ashireman <[hidden email]> wrote:

> I like the idea of a 2.0b_ series that would allow BC breaks before a 2.0
> release/final to allow some usage of the code, get wider feedback, before
> locking in and keeping BC until the next major release.
>
>
>
> Tony Shireman
>
> On Jun 22, 2011, at 3:11 PM, Bradley Holt <[hidden email]>
> wrote:
>
> > On Wed, Jun 15, 2011 at 5:03 PM, Rob Allen <[hidden email]> wrote:
> >>
> >> Hi,
> >>
> >> One thing that I think hurt ZF 1 was that we froze the API and
> introduced the no BC breakages rule from ZF 1.0. Of course, ZF 1.0 was when
> people really started using ZF and we learnt about all the use-cases that
> hadn't been thought of. I'm assuming that ZF 2's usage will go the same way
> and we won't get any serious adoption and testing until ZF 2.0 is released,
> regardless of how many betas and RCs we put out.
> >>
> >> In the light of this expectation I'd like to propose that we allow BC
> breakage between ZF 2.0 and 2.1 only and then introduce the BC requirement
> for 2.1 onwards as it would allow us to fix the mistakes we don't find until
> significantly more people are using it,
> >>
> >> Thoughts?
> >>
> >
> > -1 (sorry I'm late to the party)
> >
> > I would suggest two possible alternatives that may help.
> >
> > First, Zend Framework could adopt an odd-even release strategy for
> > minor releases. The Apache HTTP Server does this. Odd numbered minor
> > releases (e.g. 2.1) are considered beta releases and even numbered
> > minor releases (e.g. 2.2) are considered general availability (GA)
> > releases. This would allow BC changes between any odd minor release
> > and the subsequent even minor release since the previous odd minor
> > release would have been a beta version.
> >
> > This approach has the added benefit of working beyond the 2.0 release,
> > however it does not address the specific concern in the original post
> > as 2.0 would be a GA release (since it's an even numbered minor
> > release) under this scheme. I think it's important to mark a minor
> > release as a development, alpha, beta, or release candidate version if
> > users can expect BC changes in subsequent releases within the same
> > major version. This would mean sticking to 2.0b1, 2.0b2, 2.0b3 etc.
> > beta releases before the 2.0.0 GA release (I wouldn't use RC releases
> > as this implies that a GA release is imminent and would probably do
> > more harm than good). I think it's a matter of communication and time.
> > If we clearly communicate that users are expected download and try out
> > the beta releases and then make people wait long enough for 2.0.0,
> > then that should hopefully encourage people to try out the beta
> > version. In other words, keep pushing out beta releases and don't be
> > in a rush to get to 2.0 GA.
> >
> > Second, increase the pace of major releases. Both Chrome and Firefox
> > have shifted to a more rapid release cycle where major versions are
> > released as often as every six weeks. This may be a bit fast-paced for
> > Zend Framework—every 6 months might be more appropriate—but you get
> > the idea. This would help relieve some of the pressure on needing to
> > get everything perfect with each major release. I'd rather see major
> > releases with small BC changes made every six months than one large BC
> > change made with a major release every four years (ZF 1.0.0 was
> > released in July of 2007). Of course, this would bring up the issue of
> > supporting multiple major releases simultaneously, which may be a
> > problem.
> >
> > TL;DR:
> >
> > * Use an odd-even release strategy: odd minor releases are beta
> > releases, even minor releases are general availability (GA) releases
> > * Release multiple 2.0b1, 2.0b2, 2.0b3 etc. beta releases (but not RC
> > releases, as that implies a GA release is imminent) before the 2.0.0
> > GA release
> > * Clearly communicate that developers are expected to use the beta
> releases
> > * Don't be in a rush to release 2.0.0—make developers wait and use the
> > beta releases
> > * Release major versions every six months, rather than ever four
> > years, relieving the pressure on needing to get each major release
> > perfect and allowing for more BC change opportunities
> >
> > Thanks,
> > Bradley
> >
> >>
> >> Rob...
> >> --
> >> List: [hidden email]
> >> Info: http://framework.zend.com/archives
> >> Unsubscribe: [hidden email]
> >>
> >>
> >
> > --
> > List: [hidden email]
> > Info: http://framework.zend.com/archives
> > Unsubscribe: [hidden email]
> >
> >
>
> --
> List: [hidden email]
> Info: http://framework.zend.com/archives
> Unsubscribe: [hidden email]
>
>
>

[akrabat]

On 22 Jun 2011, at 23:11, Bradley Holt wrote:
>
> * Use an odd-even release strategy: odd minor releases are beta
> releases, even minor releases are general availability (GA) releases
> * Release multiple 2.0b1, 2.0b2, 2.0b3 etc. beta releases (but not RC
> releases, as that implies a GA release is imminent) before the 2.0.0
> GA release

This would imply that 2.2 is not BC with 2.0. I can't see this working given push-back on allowing a single BC break for 2.1.

> * Clearly communicate that developers are expected to use the beta releases
> * Don't be in a rush to release 2.0.0—make developers wait and use the
> beta releases

I will be interested to see how many developers actually do this with a non-trivial application.

> * Release major versions every six months, rather than ever four
> years, relieving the pressure on needing to get each major release
> perfect and allowing for more BC change opportunities

I love this! It solves all my concerns.

My thoughts and posts on this subject are entirely predicated on the assumption that ZF2's MVC system will be in actively developed, production websites until 2017 at least.  If ZF3 came out 1 year after ZF2 was released, then we can freeze API much more easily as we know we're not stuck with it for 6 years.

It also means that we don't need to worry about all the other non-MVC components so much this iteration (Zend\Pdf, Zend\Search, Zend\Mail, etc) we have ZF3 to do the major redesign work, which considerably reduces the scope of ZF2.


Regards,

Rob...


--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]