Version 4 by Evan Coury
on Feb 01, 2012 15:45.

compared with
Current by Evan Coury
on Feb 01, 2012 15:45.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (40)

View Page History
h3. NOTE: <h3>NOTE: The meeting has been moved from 17:00 UTC to 18:00 UTC due to community demand (DST).</h3>

<p>This IRC Meeting is planned for 18:00 UTC on Wednesday, 1 February 2012.</p>

{html}<iframe src="http://free.timeanddate.com/countdown/i2vpvyb9/cf12/cm0/cu4/ct0/cs0/ca0/cr0/ss0/cac000/cpc000/pcfff/tcfff/fs100/szw320/szh135/tatTime%20left%20to%20Event%20in/tac000/tptTime%20since%20Event%20started%20in/tpc000/mac000/mpc000/iso2012-02-01T18:00:00" frameborder="0" width="350" height="64"></iframe>{html}
<ac:macro ac:name="html"><ac:plain-text-body><![CDATA[<iframe src="http://free.timeanddate.com/countdown/i2vpvyb9/cf12/cm0/cu4/ct0/cs0/ca0/cr0/ss0/cac000/cpc000/pcfff/tcfff/fs100/szw320/szh135/tatTime%20left%20to%20Event%20in/tac000/tptTime%20since%20Event%20started%20in/tpc000/mac000/mpc000/iso2012-02-01T18:00:00" frameborder="0" width="350" height="64"></iframe>]]></ac:plain-text-body></ac:macro>

h2. Weekly meetings?
<h2>Weekly meetings?</h2>

During [last week's meeting|2012-01-25 Meeting Log], attendees discussed having weekly IRC meetings for the foreseeable future. Matthew would like a vote on this.
<p>During <ac:link><ri:page ri:content-title="2012-01-25 Meeting Log" /><ac:link-body>last week's meeting</ac:link-body></ac:link>, attendees discussed having weekly IRC meetings for the foreseeable future. Matthew would like a vote on this.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Should we vote on having weekly meetings?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>

h2. Zend\View Proposal By [~matthew]
<h2>Zend\View Proposal By <ac:link><ri:user ri:username="matthew" /></ac:link></h2>

The [View RFC|RFC <p>The <ac:link><ri:page ri:content-title="RFC - View Layer] Layer" /><ac:link-body>View RFC</ac:link-body></ac:link> has been up for a few weeks. While a few issues are still being worked out, a number of folks have had a chance now to play with it and examine the architecture. Matthew would like a vote on the RFC during this meeting.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Should we vote on the View Layer RFC?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>

h2. Discussion of Coding Standard Ballot Items By [~ralph]
<h2>Discussion of Coding Standard Ballot Items By <ac:link><ri:user ri:username="ralph" /></ac:link></h2>

<p>While previously discussed and approved in last weeks meeting, Ralph would like to discuss the completeness of the poll located at [POLL <ac:link><ri:page ri:content-title="POLL - Coding Standards for Type Names] Names" /></ac:link></p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Should discuss and vote on approving this poll's content?|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>

h2. PHP 5.4?
<h2>PHP 5.4?</h2>

<p>With PHP 5.4 on the verge of a stable release, the question arises: should ZF2 target PHP 5.4?</p>

<p>Pros:</p>
<ul>
* We <li>We could reduce total amount of code, and thus make maintenance easier, using traits *within* <strong>within</strong> the framework (instead of simply offering them for optional consumption).</li>
* Baseline <li>Baseline performance would improve due to the performance improvements made to PHP 5.4.</li>
* ZF2's <li>ZF2's adoption of PHP 5.4 could help with that version's adoption in distributions and ISPs. (Though this is definitely up for debate.)</li>
</ul>

Cons:
* Many developers are already targeting 5.3 since that is the version we've announced publicly for some time, and upping the version could change or upset migration plans already in place.
* PHP 5.3 adoption is still low, and 5.3 adoption is more likely in upcoming LTS distributions than 5.4.
* We cannot predict how quickly ISPs/hosting providers will offer 5.4 (and 5.3 adoption in ISPs has been slow).

One thing brought up is that we can offer some 5.4-specific features without actually building on them internally. As an example, we already have a "ProvidesEvents" trait available, which you can consume if you are on PHP 5.4, but which the framework code itself does not consume in order to stay 5.3-compatible.
<p>Cons:</p>
<ul>
<li>Many developers are already targeting 5.3 since that is the version we've announced publicly for some time, and upping the version could change or upset migration plans already in place.</li>
<li>PHP 5.3 adoption is still low, and 5.3 adoption is more likely in upcoming LTS distributions than 5.4.</li>
<li>We cannot predict how quickly ISPs/hosting providers will offer 5.4 (and 5.3 adoption in ISPs has been slow).</li>
</ul>

*The intention is not to make a decision at this point, but to gather feedback and discuss.*

<p>One thing brought up is that we can offer some 5.4-specific features without actually building on them internally. As an example, we already have a &quot;ProvidesEvents&quot; trait available, which you can consume if you are on PHP 5.4, but which the framework code itself does not consume in order to stay 5.3-compatible.</p>

<p><strong>The intention is not to make a decision at this point, but to gather feedback and discuss.</strong></p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Should we discuss using PHP 5.4?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>