Starting the 3.0 branch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

localheinz
Gary,


> I'm being flippant by the way, I appear to have been drawn into this discussion, so I guess I'd better give some reasons.
>
> 1. The quickstart is excellent, kudos to Rob Allen and other contributors who wrote it. It does expect a certain level of knowledge of OO PHP, but we seriously can't expect to write introductory documentation for people with zero PHP experience.

That's not the point. I believe the people who complain about the documentation do in fact have more than zero PHP experience.

> 2. The individual component docs where the exist are adequate, and nothing more. This could be a problem if you're the kind of person who doesn't like looking at the source code of the components you are trying to use (in which case I'd argue you have a bigger problem than the quality of documentation).

You *feel* they are adequate. Others do not.

> 3. I agree that more usable examples would be helpful. I've been saying the same thing in IRC for a few weeks.
>
> So, in my own opinion, the docs do a fine job of getting you started, but then kind of leave you hanging. I suggest if we want to continue this discussion further, we do so in a new or existing thread.

Agreed.


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

Spabby
Hi Andreas,

Could you email me personally (or in a separate thread) with some examples of where you feel existing documentation is inadequate please? I'd like to get that adressed if at all possible.

G


On Thu, Jun 20, 2013 at 9:00 AM, Andreas Möller <[hidden email]> wrote:
Gary,


> I'm being flippant by the way, I appear to have been drawn into this discussion, so I guess I'd better give some reasons.
>
> 1. The quickstart is excellent, kudos to Rob Allen and other contributors who wrote it. It does expect a certain level of knowledge of OO PHP, but we seriously can't expect to write introductory documentation for people with zero PHP experience.

That's not the point. I believe the people who complain about the documentation do in fact have more than zero PHP experience.

> 2. The individual component docs where the exist are adequate, and nothing more. This could be a problem if you're the kind of person who doesn't like looking at the source code of the components you are trying to use (in which case I'd argue you have a bigger problem than the quality of documentation).

You *feel* they are adequate. Others do not.

> 3. I agree that more usable examples would be helpful. I've been saying the same thing in IRC for a few weeks.
>
> So, in my own opinion, the docs do a fine job of getting you started, but then kind of leave you hanging. I suggest if we want to continue this discussion further, we do so in a new or existing thread.

Agreed.


Best regards,

Andreas

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

richard
The code is sufficient documentation for an experienced developer with plenty of time. 

The code is not sufficient documentation for an inexperienced developer nor an experienced developer with little time. 

To maximise the adoption rates of Zend Framework 2 for all, the barriers to entry must be minimised.

One significant barrier to entry, the documentation, exists for some categories of developers and scenarios.

The documentation HAS to be improved. This cannot be questioned rationally.

Can we please move the discussion about documentation to a HOW and do it elsewhere. 

I would like to know more about peoples cool ideas for ZF3 :)


On Thu, Jun 20, 2013 at 9:06 AM, Gary Hockin <[hidden email]> wrote:
Hi Andreas,

Could you email me personally (or in a separate thread) with some examples of where you feel existing documentation is inadequate please? I'd like to get that adressed if at all possible.

G


On Thu, Jun 20, 2013 at 9:00 AM, Andreas Möller <[hidden email]> wrote:
Gary,


> I'm being flippant by the way, I appear to have been drawn into this discussion, so I guess I'd better give some reasons.
>
> 1. The quickstart is excellent, kudos to Rob Allen and other contributors who wrote it. It does expect a certain level of knowledge of OO PHP, but we seriously can't expect to write introductory documentation for people with zero PHP experience.

That's not the point. I believe the people who complain about the documentation do in fact have more than zero PHP experience.

> 2. The individual component docs where the exist are adequate, and nothing more. This could be a problem if you're the kind of person who doesn't like looking at the source code of the components you are trying to use (in which case I'd argue you have a bigger problem than the quality of documentation).

You *feel* they are adequate. Others do not.

> 3. I agree that more usable examples would be helpful. I've been saying the same thing in IRC for a few weeks.
>
> So, in my own opinion, the docs do a fine job of getting you started, but then kind of leave you hanging. I suggest if we want to continue this discussion further, we do so in a new or existing thread.

Agreed.


Best regards,

Andreas


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

Spabby
+1 to Richard.


On Thu, Jun 20, 2013 at 9:14 AM, Richard Jennings <[hidden email]> wrote:
The code is sufficient documentation for an experienced developer with plenty of time. 

The code is not sufficient documentation for an inexperienced developer nor an experienced developer with little time. 

To maximise the adoption rates of Zend Framework 2 for all, the barriers to entry must be minimised.

One significant barrier to entry, the documentation, exists for some categories of developers and scenarios.

The documentation HAS to be improved. This cannot be questioned rationally.

Can we please move the discussion about documentation to a HOW and do it elsewhere. 

I would like to know more about peoples cool ideas for ZF3 :)


On Thu, Jun 20, 2013 at 9:06 AM, Gary Hockin <[hidden email]> wrote:
Hi Andreas,

Could you email me personally (or in a separate thread) with some examples of where you feel existing documentation is inadequate please? I'd like to get that adressed if at all possible.

G


On Thu, Jun 20, 2013 at 9:00 AM, Andreas Möller <[hidden email]> wrote:
Gary,


> I'm being flippant by the way, I appear to have been drawn into this discussion, so I guess I'd better give some reasons.
>
> 1. The quickstart is excellent, kudos to Rob Allen and other contributors who wrote it. It does expect a certain level of knowledge of OO PHP, but we seriously can't expect to write introductory documentation for people with zero PHP experience.

That's not the point. I believe the people who complain about the documentation do in fact have more than zero PHP experience.

> 2. The individual component docs where the exist are adequate, and nothing more. This could be a problem if you're the kind of person who doesn't like looking at the source code of the components you are trying to use (in which case I'd argue you have a bigger problem than the quality of documentation).

You *feel* they are adequate. Others do not.

> 3. I agree that more usable examples would be helpful. I've been saying the same thing in IRC for a few weeks.
>
> So, in my own opinion, the docs do a fine job of getting you started, but then kind of leave you hanging. I suggest if we want to continue this discussion further, we do so in a new or existing thread.

Agreed.


Best regards,

Andreas



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

EvanDotPro
In reply to this post by localheinz
On Thu, Jun 20, 2013 at 12:54 AM, Andreas Möller <[hidden email]> wrote:
Documentation should be provided by those who contribute, and not be those struggling how to understand how components work. That's the point.

First, most of the component docs have indeed been written by the authors of those components. Matthew did a great job at making all of the authors complete the docs for their components for the 2.0 release -- which is exactly what you're suggesting we do. It's already the case.

Also keep in mind, it's not always possible, either. There are often times language barriers that make this impossible; not to mention schedule / commitment issues. Very often we'll get one-off contributions from people on a "take it or leave it" basis who have no interest in communicating further or submitting an additional doc PR. We can surely ask contributors to provide docs (Matthew and some others almost always do this already), but I think rejecting perfectly valid contributions because someone doesn't know English well enough to write the documentation, or won't contribute the extra time to do docs is a toxic decision for us to make as a community.

That's my last comment on the docs/education issue. I'd say at this point, "better documentation" has been noted by everyone as a desire for 3.0 and no one has debated it -- fine. I encourage someone to start a thread with their suggestions on documentation policies so that this can continue to be debated and decided by the community in a more focused manner. (Actually I just saw, luckily before sending this, that such a thread has already been started. Thank you!)

In the meantime, please keep all the other great suggestions for 3.0 coming, everyone.

For those who missed it, we've been keeping track of the suggestions (and everyone's votes on the suggestions) on Google Moderator: http://www.google.com/moderator/#15/e=207d6f&t=207d6f.40&f=207d6f.6c2a77

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

SpiffyJr
This post has NOT been accepted by the mailing list yet.
I'd like to *modularize* ZF2 and place an emphasis on *components* and not the entire library stack. With advances to dependency management (composer) there is no reason we need a gigantic library with every component. Each component could be setup similar to a generic module structure.

This makes reducing dependencies on components much easier by providing a clear separation from the rest of the framework. If I want to work on zend-view I should be able to clone it, composer install --dev, and be able to test that component against it's dependencies alone.

Modules were a *great* step forward for ZF2 but we could take that a step further by making it *easier* to both use and contribute to individual ZF2 components. This also has an additional benefit of greatly simplifying what dependencies each component/module requires.

Example,

I want to add a new feature to zend-stdlib.

* git clone git://github.com:zendframework/zend-stdlib.git
* cd zend-stdlib
* composer install --dev
* ./vendor/bin/phpunit test (running tests should be *that* easy)
* add new features
* ./vendor/bin/phpunit test (verify)
* git commit && git push

Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4
Kyle S
blogs @ www.spiffyjr.me
github @ www.github.com/spiffyjr
follow @ www.twitter.com/spiffyjr
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

EvanDotPro
In reply to this post by Gregory
On Mon, Jun 24, 2013 at 7:02 AM, Zachary Burnham <[hidden email]> wrote:
I understand what you're saying.  I think what people would like to
see is the same standard applied to documentation as is to tests when
a PR is submitted.  (Awkward grammar there, yuck.)  I wouldn't send a
PR without tests for the new/edited code, because I know that it would
probably be kicked back at me until I added tests.  (At least, that's
the impression that I get.)  I think that perhaps the same standard
should be applied to docs; granted, not every PR has new functionality
that requires docs (bug fixes that don't change how something works,
for example, especially since we don't want to break BC under most
circumstances) but those that do should probably have a documentation
requirement enforced.

I agree, this would be nice in a "perfect world" where all contributors are also great, English-speaking technical writers, but it's simply not the case.

As I mentioned earlier in this thread, this is largely (though not exclusively) already the case -- most of the component docs we have today, were indeed, written by the contributor(s)/author(s) for those components. However, I also believe that this practice is actually partially to blame for many of the complaints we end up getting about the current docs. They're not written with a beginner or larger context in mind because they're written by someone that's far too close to the code to write quality end-user documentation for it. I think there's definitely ways to solve the doc problems, but requiring docs along with contributions is, in my opinion, not the optimal solution -- it will result in improving the quantity of documentation, but not increase the quality, which as I see it, needs to be our priority.

Again, this thread is getting off topic from my intent of planning ZF3.0 development. "Better docs" has definitely been noted and agreed upon, but let's move the discussion on the specifics over to the "How to improve the docs" thread.

--
Evan Coury
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Gregory
In reply to this post by Gregory
The comment was worded carefully for it not to be directed at the existing development team, but further consideration. So no offence was intended.

However that said, I would ask if consideration could be made towards how design decisions, have been made and are documented - this could help for others to quickly follow up and revise them into better docs etc, i.e. RFCs, IRC, email, IRC...

@evan, you moved the dicussion to google in your second post? :)






On Mon, Jun 24, 2013 at 8:55 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
On Thu, Jun 20, 2013 at 1:05 AM, Gregory <[hidden email]> wrote:
> I started programming when I was 8 years old, I failed my first programming
> course because of the little to no documentation. I was taught that coding
> is 80% documentation regardless of how good it is.
>
> For it to be an enterprise level framework, there has to be Zend driven
> documentation, they are the fall back support when all else fails and
> companies needs assurance. On top of which, good documentation alone will
> drive actual code development and bug fixes.

I need to clarify something here for everyone on this thread.

Zend employs three people full time for Zend Framework: myself, Ralph,
and Enrico. That's it.

Do you know how many contributors we have? Thousands.

On top of that, none of the three of us are actually technical writers
(though I come close, as I was a credit shy of an English minor in
college).

My point is that Zend is not providing infinite resources to the
framework. Zend is providing stewardship and direction, but we do not
and cannot drive all initiatives, and that includes documentation. We
have to pick and choose, and typically we need to err on the side of
code, and, in particular, maintenance / new features.

On top of this, we are hardly the best suited to write the
documentation, as we are too close to the code. Documentation we write
often is aimed at our own peers -- which is hardly of help to a
newcomer to PHP or ZF, who likely will have highly specific needs that
we're not even considering.

This does not mean we feel documentation is not important -- but it
does mean that we need to leverage the community as much as possible
to help drive documentation. Those who use the documentation are often
also the ones best suited to write it.

--
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



--
Greg
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Justin Martin
In reply to this post by EvanDotPro
On 13-06-24 07:17 AM, Evan Coury wrote:
I agree, this would be nice in a "perfect world" where all contributors are also great, English-speaking technical writers, but it's simply not the case.

As I mentioned earlier in this thread, this is largely (though not exclusively) already the case -- most of the component docs we have today, were indeed, written by the contributor(s)/author(s) for those components. However, I also believe that this practice is actually partially to blame for many of the complaints we end up getting about the current docs. They're not written with a beginner or larger context in mind because they're written by someone that's far too close to the code to write quality end-user documentation for it. I think there's definitely ways to solve the doc problems, but requiring docs along with contributions is, in my opinion, not the optimal solution -- it will result in improving the quantity of documentation, but not increase the quality, which as I see it, needs to be our priority.

Again, this thread is getting off topic from my intent of planning ZF3.0 development. "Better docs" has definitely been noted and agreed upon, but let's move the discussion on the specifics over to the "How to improve the docs" thread.

--
Evan Coury

Jumping into the shark pit, here. Not sure if it'd be better directed towards the other thread, but I have a few remarks to make on the issue of documentation.

It should be noted that the old refrain of "make the developers do it!" is completely and totally ineffective. Firstly, developers *suck* at writing their own documentation. The reasons for this are plentiful.
Even extremely talented programmers can be poor communicators. They are not always equipped with the skills to write effective and useful documentation.
The person writing the code often has *too much* context on what the code does, to be able to discern where confusion may arise. A "fresh perspective" is very important in writing effective documentation.
When you force developers to write their own documentation, they do it as an afterthought, and usually resentfully, instead of considering it a contribution unto itself.
Some developers simply will refuse. It's easy to say "We'll just reject their contributions" in that case, but the reality is that those developers are often excellent contributors to the codebase, and rather crappy documentation writers.

In my experience, the *best* documentation is that written by dedicated documentation editors. This is how the PHP manual is written. It does make it *much harder* to find documentation contributors, but I would argue that having *more* documentation people isn't necessarily so important as having *good* documentation people.

I have a number of suggestions regarding specific ways we can improve the documentation, and would be more than willing to assist in the process. However, I'll leave those suggestions to another thread where the passion of this thread isn't present. :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Marco Pivetta
Posting on behalf of Kyle Spraggs (SpiffyJr) who is having issues with nabble:

I'd like to *modularize* ZF2 and place an emphasis on *components* and not the entire library stack. With advances to dependency management (composer) there is no reason we need a gigantic library with every component. Each component could be setup similar to a generic module structure.

This makes reducing dependencies on components much easier by providing a clear separation from the rest of the framework. If I want to work on zend-view I should be able to clone it, composer install --dev, and be able to test that component against it's dependencies alone.

Modules were a *great* step forward for ZF2 but we could take that a step further by making it *easier* to both use and contribute to individual ZF2 components. This also has an additional benefit of greatly simplifying what dependencies each component/module requires.

Example,

I want to add a new feature to zend-stdlib.

* git clone git://github.com:zendframework/zend-stdlib.git
* cd zend-stdlib
* composer install --dev
* ./vendor/bin/phpunit test (running tests should be *that* easy)
* add new features
* ./vendor/bin/phpunit test (verify)
* git commit && git push

Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Spabby
Marco,

That's the best idea ever and I heartily agree with you.

G


On Mon, Jun 24, 2013 at 7:01 PM, Marco Pivetta <[hidden email]> wrote:
Posting on behalf of Kyle Spraggs (SpiffyJr) who is having issues with nabble:

I'd like to *modularize* ZF2 and place an emphasis on *components* and not the entire library stack. With advances to dependency management (composer) there is no reason we need a gigantic library with every component. Each component could be setup similar to a generic module structure.

This makes reducing dependencies on components much easier by providing a clear separation from the rest of the framework. If I want to work on zend-view I should be able to clone it, composer install --dev, and be able to test that component against it's dependencies alone.

Modules were a *great* step forward for ZF2 but we could take that a step further by making it *easier* to both use and contribute to individual ZF2 components. This also has an additional benefit of greatly simplifying what dependencies each component/module requires.

Example,

I want to add a new feature to zend-stdlib.

* git clone git://github.com:zendframework/zend-stdlib.git
* cd zend-stdlib
* composer install --dev
* ./vendor/bin/phpunit test (running tests should be *that* easy)
* add new features
* ./vendor/bin/phpunit test (verify)
* git commit && git push

Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Spabby
Going back to the original topic...

In 3.0 I'd like to see the whole framework re-written using PHPSpec.


G


On Mon, Jun 24, 2013 at 7:16 PM, Gary Hockin <[hidden email]> wrote:
Marco,

That's the best idea ever and I heartily agree with you.

G


On Mon, Jun 24, 2013 at 7:01 PM, Marco Pivetta <[hidden email]> wrote:
Posting on behalf of Kyle Spraggs (SpiffyJr) who is having issues with nabble:

I'd like to *modularize* ZF2 and place an emphasis on *components* and not the entire library stack. With advances to dependency management (composer) there is no reason we need a gigantic library with every component. Each component could be setup similar to a generic module structure.

This makes reducing dependencies on components much easier by providing a clear separation from the rest of the framework. If I want to work on zend-view I should be able to clone it, composer install --dev, and be able to test that component against it's dependencies alone.

Modules were a *great* step forward for ZF2 but we could take that a step further by making it *easier* to both use and contribute to individual ZF2 components. This also has an additional benefit of greatly simplifying what dependencies each component/module requires.

Example,

I want to add a new feature to zend-stdlib.

* git clone git://github.com:zendframework/zend-stdlib.git
* cd zend-stdlib
* composer install --dev
* ./vendor/bin/phpunit test (running tests should be *that* easy)
* add new features
* ./vendor/bin/phpunit test (verify)
* git commit && git push

Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

Ben Scholzen 'DASPRiD'
In reply to this post by Marco Pivetta
On 24.06.2013 20:01, Marco Pivetta wrote:
> I'd like to *modularize* ZF2 and place an emphasis on *components* and
> not the entire library stack. With advances to dependency management
> (composer) there is no reason we need a gigantic library with every
> component. Each component could be setup similar to a generic module
> structure.

Totally agree on this one. The zendframework/zendframework package could
then be a virtual package which just provides dependencies on all zf
components.

--
Ben Scholzen 'DASPRiD'
Community Review Team Member | [hidden email]
Zend Framework               | http://www.dasprids.de
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

weierophinney
Administrator
In reply to this post by Spabby
On Mon, Jun 24, 2013 at 1:25 PM, Gary Hockin <[hidden email]> wrote:
> Going back to the original topic...
>
> In 3.0 I'd like to see the whole framework re-written using PHPSpec.

I doubt we'll go this route, for the simple reason that while PHPUnit
experience is relatively easy to find, PHPSpec experience is much
harder, and would require another learning curve for even _existing_
contributors.


> On Mon, Jun 24, 2013 at 7:16 PM, Gary Hockin <[hidden email]> wrote:
>>
>> Marco,
>>
>> That's the best idea ever and I heartily agree with you.
>>
>> G
>>
>>
>> On Mon, Jun 24, 2013 at 7:01 PM, Marco Pivetta <[hidden email]> wrote:
>>>
>>> Posting on behalf of Kyle Spraggs (SpiffyJr) who is having issues with
>>> nabble:
>>>
>>> I'd like to *modularize* ZF2 and place an emphasis on *components* and
>>> not the entire library stack. With advances to dependency management
>>> (composer) there is no reason we need a gigantic library with every
>>> component. Each component could be setup similar to a generic module
>>> structure.
>>>
>>> This makes reducing dependencies on components much easier by providing a
>>> clear separation from the rest of the framework. If I want to work on
>>> zend-view I should be able to clone it, composer install --dev, and be able
>>> to test that component against it's dependencies alone.
>>>
>>> Modules were a *great* step forward for ZF2 but we could take that a step
>>> further by making it *easier* to both use and contribute to individual ZF2
>>> components. This also has an additional benefit of greatly simplifying what
>>> dependencies each component/module requires.
>>>
>>> Example,
>>>
>>> I want to add a new feature to zend-stdlib.
>>>
>>> * git clone git://github.com:zendframework/zend-stdlib.git
>>> * cd zend-stdlib
>>> * composer install --dev
>>> * ./vendor/bin/phpunit test (running tests should be *that* easy)
>>> * add new features
>>> * ./vendor/bin/phpunit test (verify)
>>> * git commit && git push
>>>
>>> Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4
>>
>>
>



--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Sascha-Oliver Prolic
In reply to this post by Marco Pivetta
Well, generally it sounds like a great idea, Linus would be proud of us! :-)
However I have some questions regarding how we work or should work then:

Working on a feature in multiple components, requires referencing pull requests into several repositories. Travis would fail, because the other component as not yet merged and vica versa.

If we have common versioning for all components (we release ZF 2.3.0 with all subcomponents in distinct repositories) that implies:
- We release Zend\Auth 2.3.0, Zend\Db 2.3.0, and so on.
- We have some components marking new features or even new major releases with no code changes, perhabs not even a single line of code changed between releases.

If we have distinct versioning for all components:
- We release Zend\Auth 2.3.0, Zend\Db 2.3.0, but we keep Zend\Config 2.2.2, because nothing changed.
- We should deprecate Zend\Version, or have only interfaces there, perhabs a Zend\Compontent\Version class per subcomponent.
- Tie the framework together with git submodules or composer.
- Contra: If we move code between components, e.g. from Zend\SomeComponent into Zend\Stdlib, what could happen by time, we lose the history. Of course you can look it up manually, but git won't know about it.

Distinct versioning might lead to problems, because you can run into issues with components that expect a specifc version from another component, that could be forgotten to get updated, or lead to lots of issues being posted, that are just because if version conflicts.

However it is awkward to have a Zend\Component from 2.2.2, 2.2.3, 2.3.0, 2.3.1, 2.3.2, and so on, with no single line of code changed. It's like, hey we have something new to you, new features, new major release (3.0.0) of a Zend Framework component, but ... haha, nothing new in it.

In my opinion, when we split the repository into a repository per component, we should also talk about distinct versioning.

Thoughts?

Sascha-Oliver Prolic

2013/6/24 Marco Pivetta <[hidden email]>
Posting on behalf of Kyle Spraggs (SpiffyJr) who is having issues with nabble:

I'd like to *modularize* ZF2 and place an emphasis on *components* and not the entire library stack. With advances to dependency management (composer) there is no reason we need a gigantic library with every component. Each component could be setup similar to a generic module structure.

This makes reducing dependencies on components much easier by providing a clear separation from the rest of the framework. If I want to work on zend-view I should be able to clone it, composer install --dev, and be able to test that component against it's dependencies alone.

Modules were a *great* step forward for ZF2 but we could take that a step further by making it *easier* to both use and contribute to individual ZF2 components. This also has an additional benefit of greatly simplifying what dependencies each component/module requires.

Example,

I want to add a new feature to zend-stdlib.

* git clone git://github.com:zendframework/zend-stdlib.git
* cd zend-stdlib
* composer install --dev
* ./vendor/bin/phpunit test (running tests should be *that* easy)
* add new features
* ./vendor/bin/phpunit test (verify)
* git commit && git push

Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4



--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AW: [zf-contributors] Starting the 3.0 branch

Kyle Spraggs
In the case of separate components I would argue that the "core" would have a major version increase even if the components inside it didn't necessarily update.

e.g., assume ZF "core" consists of form, mvc, stdlib, view.

ZF 3.0
Zend\Form: 2.3
Zend\Mvc: 3.0
Zend\Stdlib: 2.3.4
Zend\View: 3.0

Nothing wrong with that, imo.


Kyle Spraggs
"There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries." - WIlliam Shakespeare


On Tue, Jun 25, 2013 at 9:20 AM, Sascha-Oliver Prolic <[hidden email]> wrote:
Well, generally it sounds like a great idea, Linus would be proud of us! :-)
However I have some questions regarding how we work or should work then:

Working on a feature in multiple components, requires referencing pull requests into several repositories. Travis would fail, because the other component as not yet merged and vica versa.

If we have common versioning for all components (we release ZF 2.3.0 with all subcomponents in distinct repositories) that implies:
- We release Zend\Auth 2.3.0, Zend\Db 2.3.0, and so on.
- We have some components marking new features or even new major releases with no code changes, perhabs not even a single line of code changed between releases.

If we have distinct versioning for all components:
- We release Zend\Auth 2.3.0, Zend\Db 2.3.0, but we keep Zend\Config 2.2.2, because nothing changed.
- We should deprecate Zend\Version, or have only interfaces there, perhabs a Zend\Compontent\Version class per subcomponent.
- Tie the framework together with git submodules or composer.
- Contra: If we move code between components, e.g. from Zend\SomeComponent into Zend\Stdlib, what could happen by time, we lose the history. Of course you can look it up manually, but git won't know about it.

Distinct versioning might lead to problems, because you can run into issues with components that expect a specifc version from another component, that could be forgotten to get updated, or lead to lots of issues being posted, that are just because if version conflicts.

However it is awkward to have a Zend\Component from 2.2.2, 2.2.3, 2.3.0, 2.3.1, 2.3.2, and so on, with no single line of code changed. It's like, hey we have something new to you, new features, new major release (3.0.0) of a Zend Framework component, but ... haha, nothing new in it.

In my opinion, when we split the repository into a repository per component, we should also talk about distinct versioning.

Thoughts?

Sascha-Oliver Prolic

2013/6/24 Marco Pivetta <[hidden email]>
Posting on behalf of Kyle Spraggs (SpiffyJr) who is having issues with nabble:

I'd like to *modularize* ZF2 and place an emphasis on *components* and not the entire library stack. With advances to dependency management (composer) there is no reason we need a gigantic library with every component. Each component could be setup similar to a generic module structure.

This makes reducing dependencies on components much easier by providing a clear separation from the rest of the framework. If I want to work on zend-view I should be able to clone it, composer install --dev, and be able to test that component against it's dependencies alone.

Modules were a *great* step forward for ZF2 but we could take that a step further by making it *easier* to both use and contribute to individual ZF2 components. This also has an additional benefit of greatly simplifying what dependencies each component/module requires.

Example,

I want to add a new feature to zend-stdlib.

* git clone git://github.com:zendframework/zend-stdlib.git
* cd zend-stdlib
* composer install --dev
* ./vendor/bin/phpunit test (running tests should be *that* easy)
* add new features
* ./vendor/bin/phpunit test (verify)
* git commit && git push

Thoughts? http://www.google.com/moderator/#8/e=207d6f&q=207d6f.6b2d39&v=4



--
Sascha-Oliver Prolic

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

automatix
In reply to this post by Xerkus
OK, we can allow an exception for the Module classe. But there are more such places in th code. Examples: ArraySerializable, ResultSet. I've just searched for the string "method_exists" with the fulltext search of my IDE and found ove 130 occurences. OK, sometimes (!) it might actually make sense, but in my opinion it's not a good design decision to replace interfaces / instanceof with such checks. (Usage of) Interfaces would make the code cleaner and better comprehensible.



Am 08.06.2013 21:13, schrieb Aleksey Khudyakov:
On 08.06.2013 1:36, Ilya Khanataev wrote:
Hello!

There are some places in ZF2, where method checks are used instead of interfaces. E.g. the for configs in the Module class. It would be great, if the ZF3 would use interfaces in such cases: 1. It's a clean object oriented way. 2. It makes the application/framework more transparent and understandable (especially for the framework newbies).

Interfaces in Module class was made optional to allow to reuse modules outside of zf2 while not introducing dependency on it (if those interfaces is the only part required zf2).

Other than that i agree.

-- 
Aleksey Khudyakov
Web developer, ZCE

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

weierophinney
Administrator
On Thu, Jun 27, 2013 at 6:10 AM, Ilya Khanataev <[hidden email]> wrote:
> OK, we can allow an exception for the Module classe. But there are more such
> places in th code. Examples: ArraySerializable, ResultSet. I've just
> searched for the string "method_exists" with the fulltext search of my IDE
> and found ove 130 occurences. OK, sometimes (!) it might actually make
> sense, but in my opinion it's not a good design decision to replace
> interfaces / instanceof with such checks. (Usage of) Interfaces would make
> the code cleaner and better comprehensible.


You're missing the end of that sentence: "... for the subset of ZF
developers that are already trained and of moderate to advanced
skill."

Don't get me wrong -- I love interfaces, and have advocated contract
oriented development for ZF2. However, in terms of consumption,
interfaces mean that incoming developers MUST understand OOP well.
It's far harder for a developer who barely understands OOP to grasp
interfaces than it is for them to understand "write this method."

What we've done in ZF2 is largely allow GO-style interfaces, similar
to the "Protocol Type Hinting" proposal Anthony Ferrara raised
recently (https://wiki.php.net/rfc/protocol_type_hinting); we're
simply doing it in userland. This gives us the following benefits:

- Easier for developers to implement
- Allows multiple inheritance in more flexible ways
- Prevents conflicts between existing code and ZF code

Furthermore, in modern PHP versions, method_exists() does not provide
a noticeable performance issue.

While I understand the arguments for doing strict interface-only type
hinting, I think the benefits we achieve with the approaches we're
using are important and beneficial to users.



--
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

Stefano Torresi
This post has NOT been accepted by the mailing list yet.
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Starting the 3.0 branch

Corentin Larose - QAPA
In reply to this post by EvanDotPro
Hello eveyone,

I would like to propose a Coding Standard (or convention) for the methods order in a class.

- Since there is no real trivial order to respect, you can often observe two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only trivial/consensual possibility (often used also in css).

Some special pre order could happen for static/private/protected/public/magic methods, even if I'm not sure if it would be very interesting.

Intended goal would be to be able to put a new method in a class without wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA

Le 30/05/2013 15:21, Evan Coury a écrit :
Hi everyone!

(Sorry, I meant to send this earlier, but had some email issues.)

I'd like to begin the process of getting our 3.0 branch started.

Besides the obvious of making use of 5.4 features such as traits, I think we should come up with some sort of list of goals / ideas for ZF 3.0, to start getting an idea of what we want to work towards. I'll also be starting and maintaining a 3.0 branch in the near future so that we'll have somewhere to begin merging pull requests that can't fit into a 2.x release.

To get things started:

- PHP 5.4 (minimum), utilizing features such as traits internally in the framework.
- While we have the freedom to break BC for 3.0, we need to keep it much less dramatic as what we saw from ZF1 -> ZF2 -- we should keep track of BC breaks as we introduce them into a 3.0 branch and make sure each one is well-justified.
- Remove all deprecated methods and classes that are in 2.x for the purpose of backwards compatibility.
- ???

Once we have some good ideas floating around, I'll compile them into a wiki page and we'll have something clear to start with.

Please do not bring up ZF2 support lifetime or which PHP version ZF3 should require in this thread -- if you want to have those discussions, feel free to start another thread.

--
Evan Coury, ZCE

12345
Loading...