Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] Re: Hold off 5.4 [RSS Feed]

#1 Nov. 25, 2010 01:31:10

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <m***@*hp.net> wrote:
> On 11/23/2010 02:30 AM, Felipe Pena wrote:

>> 5.4 should be hold off until we solved the listed issues and the
>> release management RFC gets discussed and hopefully approved.
>
> +1

+1 here too.

--
Pierre

@pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#2 Nov. 25, 2010 07:17:56

Davey S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:

> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <m***@*hp.net> wrote:
>> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>
>>> 5.4 should be hold off until we solved the listed issues and the
>>> release management RFC gets discussed and hopefully approved.

The reality is that trunk is not going to be 5.4; it cannot be in its current
state.

The reason behind ditching the unicode php6 was to enable innovation in trunk.
This meant
we could have traits, type hinting, apc in core etc, as well as internal
enhancements, the new lemon
parser etc. Regardless of the arguments and unresolved issues, this IS
happening, and IS a good thing.

The goal then was to essentially take the 5.3 branch, create a 5.4 branch,
cherry pick commits to trunk
and apply them to the 5.4 branch and end up with a stable build. Unfortunately,
subversion merging sucks.

This is an unreliable, laborious, crappy method for creating stable branches,
and managing the
repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so
creating feature branches and
re-integrating is also a pretty crappy solution.

So, with the BC breaks committed to trunk (register globals) or that we want to
commit to trunk (magic quotes), as
well as the code without consensus, creating a stable 5.4 branch is going to be
a lot of work.

Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main
repo, but have several small projects on
github), but it seems that it's capabilities would make these things much more
trivial. Obviously: not a solution for now.

We need to get our repo in order first, then we can start talking about 5.4.
The RMs need to make a definitive
stand about how the repo will be managed, and explain to us how that's going to
trickle down to our personal habits.

This doesn't seem the ideal time to introduce a new toolchain, so sticking with
SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes +
security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).

Non-agreed upon enhancements, potential BC breaks, all should be done in
feature branches. This gives people buildable
(hopefully) branches to use for testing, revision control for those developing
the features, and unmuddied commit histories
to more easily pull those changes into the appropriate branches.

- Davey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Nov. 25, 2010 07:50:42

Patrick A.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


2010/11/25 Davey Shafik <da***@*hp.net>:
>
> On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
>
>> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <m***@*hp.net> wrote:
>>> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>>
>>>> 5.4 should be hold off until we solved the listed issues and the
>>>> release management RFC gets discussed and hopefully approved.
>
> The reality is that trunk is not going to be 5.4; it cannot be in its current
> state.
>
> The reason behind ditching the unicode php6 was to enable innovation in
> trunk. This meant
> we could have traits, type hinting, apc in core etc, as well as internal
> enhancements, the new lemon
> parser etc. Regardless of the arguments and unresolved issues, this IS
> happening, and IS a good thing.
>
> The goal then was to essentially take the 5.3 branch, create a 5.4 branch,
> cherry pick commits to trunk
> and apply them to the 5.4 branch and end up with a stable build.
> Unfortunately, subversion merging sucks.
>
> This is an unreliable, laborious, crappy method for creating stable branches,
> and managing the
> repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so
> creating feature branches and
> re-integrating is also a pretty crappy solution.
>
> So, with the BC breaks committed to trunk (register globals) or that we want
> to commit to trunk (magic quotes), as
> well as the code without consensus, creating a stable 5.4 branch is going to
> be a lot of work.
>
> Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main
> repo, but have several small projects on
> github), but it seems that it's capabilities would make these things much
> more trivial. Obviously: not a solution for now.
>
> We need to get our repo in order first, then we can start talking about 5.4.
> The RMs need to make a definitive
> stand about how the repo will be managed, and explain to us how that's going
> to trickle down to our personal habits.
>
> This doesn't seem the ideal time to introduce a new toolchain, so sticking
> with SVN, we should  maintain 4 branches, 5.2 (security only), 5.3 (bug fixes
> + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).
>
> Non-agreed upon enhancements, potential BC breaks, all should be done in
> feature branches. This gives people buildable
> (hopefully) branches to use for testing, revision control for those
> developing the features, and unmuddied commit histories
> to more easily pull those changes into the appropriate branches.
>
> - Davey
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.phpI think Davey has a clear view and a good explanation about the
current situation.
Trunk has been used for both short and long term development hence the
difficulties to agree that trunk is about 5.4 or +.

In a first place, we should decide on what to have for 5.4 and what to
leave for the future.

A technical way to do it would be to use git-svn locally, starting
from the PHP_5_3 branch and merging it with trunk. git rebase -i can
then be used easily to remove all the commits we don't want to appear
in 5.4.

--
Patrick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#4 Nov. 25, 2010 08:27:04

Jani T.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


Who says it has to be 5.4? People seem to be a bit fixated on the version
there.
Major BC breaks just means the version released from trunk is 6.0. And it's
just a number. Big number, but still just a number.

Merging (by and or by magic :) features into branch created from 5.3 just
sounds like plane crash waiting to happen..

---Jani



On Nov 25, 2010, at 9:16 AM, Davey Shafik wrote:

>
> On Nov 24, 2010, at 8:29 PM, Pierre Joye wrote:
>
>> On Tue, Nov 23, 2010 at 1:41 PM, Michael Wallner <m***@*hp.net> wrote:
>>> On 11/23/2010 02:30 AM, Felipe Pena wrote:
>>
>>>> 5.4 should be hold off until we solved the listed issues and the
>>>> release management RFC gets discussed and hopefully approved.
>
> The reality is that trunk is not going to be 5.4; it cannot be in its current
> state.
>
> The reason behind ditching the unicode php6 was to enable innovation in
> trunk. This meant
> we could have traits, type hinting, apc in core etc, as well as internal
> enhancements, the new lemon
> parser etc. Regardless of the arguments and unresolved issues, this IS
> happening, and IS a good thing.
>
> The goal then was to essentially take the 5.3 branch, create a 5.4 branch,
> cherry pick commits to trunk
> and apply them to the 5.4 branch and end up with a stable build.
> Unfortunately, subversion merging sucks.
>
> This is an unreliable, laborious, crappy method for creating stable branches,
> and managing the
> repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so
> creating feature branches and
> re-integrating is also a pretty crappy solution.
>
> So, with the BC breaks committed to trunk (register globals) or that we want
> to commit to trunk (magic quotes), as
> well as the code without consensus, creating a stable 5.4 branch is going to
> be a lot of work.
>
> Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main
> repo, but have several small projects on
> github), but it seems that it's capabilities would make these things much
> more trivial. Obviously: not a solution for now.
>
> We need to get our repo in order first, then we can start talking about 5.4.
> The RMs need to make a definitive
> stand about how the repo will be managed, and explain to us how that's going
> to trickle down to our personal habits.
>
> This doesn't seem the ideal time to introduce a new toolchain, so sticking
> with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes
> + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).
>
> Non-agreed upon enhancements, potential BC breaks, all should be done in
> feature branches. This gives people buildable
> (hopefully) branches to use for testing, revision control for those
> developing the features, and unmuddied commit histories
> to more easily pull those changes into the appropriate branches.
>
> - Davey
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Nov. 25, 2010 11:47:27

Patrick A.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


2010/11/25 Jani Taskinen <jani.taski***@*ki.fi>:
> Who says it has to be 5.4? People seem to be a bit fixated on the version
> there.

I'd like to know too...

> Major BC breaks just means the version released from trunk is 6.0. And it's
> just a number. Big number, but still just a number.

Well, such a change tends to create a big buzz, without mentioning
stuff like certifications, trainings,...

We should avoid creating a virtual PHP 6.0 which will contain all the
BC stuff while all features appears in 5.x.
By doing so we will keep some shit in 5.x forever and won't have
anything appealing enough to migrate to 6.0!

> Merging (by and or by magic :) features into branch created from 5.3 just
> sounds like plane crash waiting to happen..
>
> ---Jani

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#6 Nov. 25, 2010 12:47:39

Jani T.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:

> 2010/11/25 Jani Taskinen <jani.taski***@*ki.fi>:
>> Who says it has to be 5.4? People seem to be a bit fixated on the version
>> there.
>
> I'd like to know too...
>
>> Major BC breaks just means the version released from trunk is 6.0. And it's
>> just a number. Big number, but still just a number.
>
> Well, such a change tends to create a big buzz, without mentioning
> stuff like certifications, trainings,...

This is a joke, right?

> We should avoid creating a virtual PHP 6.0 which will contain all the
> BC stuff while all features appears in 5.x.
> By doing so we will keep some shit in 5.x forever and won't have
> anything appealing enough to migrate to 6.0

..or have something really new and interesting in PHP 7.0.0. The big version
number change is reserved for BC changing stuff, not just for "fancy new stuff".

--Jani


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#7 Nov. 25, 2010 13:00:51

James B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


Slightly brambly thoughts...
I think (imho) the PHP6 hype in user land died down long ago after it became
obvious it wouldn't materialise any time soon. It would be nice to see 6 to
appear if only to break the (apparent) deadlock that the Unicode stuff brought
on(I realise this is not enough justification by itself)
What will this mean to all the Hosting providers etc who are still finishing
long running 4->5 or 5.x -> 5.3 migrations? Will they resist change more
because it looks like a bigger change regardless of the underlying code? As
they provide installs/hosting for what I can guess to be a huge amount of the
PHP's actual users is it factor that's worth considering

I realise this is a Friday afternoon category comment but it can't wait..
Think of all of those PHP6 books that will be reduced to near junk status in
swift branch/commit action
And as a bonus

-----Original Message-----
From: Jani Taskinen

On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:

> 2010/11/25 Jani Taskinen <jani.taski***@*ki.fi>:
>> Who says it has to be 5.4? People seem to be a bit fixated on the version
>> there.
>
> I'd like to know too...
>
>> Major BC breaks just means the version released from trunk is 6.0. And it's
>> just a number. Big number, but still just a number.
>
> Well, such a change tends to create a big buzz, without mentioning
> stuff like certifications, trainings,...

This is a joke, right?

> We should avoid creating a virtual PHP 6.0 which will contain all the
> BC stuff while all features appears in 5.x.
> By doing so we will keep some shit in 5.x forever and won't have
> anything appealing enough to migrate to 6.0

..or have something really new and interesting in PHP 7.0.0. The big version
number change is reserved for BC changing stuff, not just for "fancy new stuff".

--Jani



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#8 Nov. 25, 2010 13:03:00

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


May I ask not to begin with that again? The php 2034 thing?

Let sort out what has to be sorted out, like the current proposals. In
the short term, a 5.x (with BC) is what users and developers are
looking for. We can then begin to think about the next big step.

On Thu, Nov 25, 2010 at 1:58 PM, James Butler
<james.but***@*digitalresearch.com> wrote:
> Slightly brambly thoughts...
> I think (imho) the PHP6 hype in user land died down long ago after it became
> obvious it wouldn't materialise any time soon. It would be nice to see 6 to
> appear if only to break the (apparent) deadlock that the Unicode stuff
> brought on(I realise this is not enough justification by itself)
> What will this mean to all the Hosting providers etc who are still finishing
> long running 4->5 or  5.x -> 5.3 migrations? Will they resist change more
> because it looks like a bigger change regardless of the underlying code? As
> they provide installs/hosting for what I can guess to be a huge amount of the
> PHP's actual users is it factor that's worth considering
>
> I realise this is a Friday afternoon category comment but it can't wait..
> Think of all of those PHP6 books that will be reduced to near junk status in
> swift branch/commit action
> And as a bonus
>
> -----Original Message-----
> From: Jani Taskinen
>
> On Nov 25, 2010, at 1:46 PM, Patrick ALLAERT wrote:
>
>> 2010/11/25 Jani Taskinen <jani.taski***@*ki.fi>:
>>> Who says it has to be 5.4? People seem to be a bit fixated on the version
>>> there.
>>
>> I'd like to know too...
>>
>>> Major BC breaks just means the version released from trunk is 6.0. And it's
>>> just a number. Big number, but still just a number.
>>
>> Well, such a change tends to create a big buzz, without mentioning
>> stuff like certifications, trainings,...
>
> This is a joke, right?
>
>> We should avoid creating a virtual PHP 6.0 which will contain all the
>> BC stuff while all features appears in 5.x.
>> By doing so we will keep some shit in 5.x forever and won't have
>> anything appealing enough to migrate to 6.0
>
> ..or have something really new and interesting in PHP 7.0.0. The big version
> number change is reserved for BC changing stuff, not just for "fancy new
> stuff".
>
> --Jani
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
>



--
Pierre

@pierrejoye |http://blog.thepimp.net|http://www.libgd.org--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#9 Nov. 25, 2010 14:06:41

Derick R.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


On Thu, 25 Nov 2010, Davey Shafik wrote:

> The goal then was to essentially take the 5.3 branch, create a 5.4
> branch, cherry pick commits to trunk and apply them to the 5.4 branch
> and end up with a stable build. Unfortunately, subversion merging
> sucks.

This has nothing to do with any sort of version control sucking. Cherry
picking is hard! It only works if you get one feature in one commit,
instead of many several, with other changes in between, without many
dependices between patches. PHP isn't like that, especially with
Dmitry's engine changing patches.

> This doesn't seem the ideal time to introduce a new toolchain, so
> sticking with SVN, we should maintain 4 branches, 5.2 (security only),
> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC
> breaks), 6.0 (BC breaks).

Four branches? Are you going to help?

> Non-agreed upon enhancements, potential BC breaks, all should be done
> in feature branches.

That's a good theoretical point of view. And I maintain it doesn't work.
It makes it for example very difficult to try out multiple new features
at the same time; to say, to try to figure our whethr your app will
still works. It's also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible (that's also why I am not a fan of DVCS, because it reduces
that exposure drastically).

Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#10 Nov. 25, 2010 15:03:14

Gustavo L.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] Re: Hold off 5.4


On Thu, 25 Nov 2010 14:05:43 -0000, Derick Rethans <der***@*hp.net> wrote:On Thu, 25 Nov 2010, Davey Shafik wrote:The goal then was to essentially take the 5.3 branch, create a 5.4
branch, cherry pick commits to trunk and apply them to the 5.4 branch
and end up with a stable build. Unfortunately, subversion merging
sucks.This has nothing to do with any sort of version control sucking. Cherry
picking is hard! It only works if you get one feature in one commit,
instead of many several, with other changes in between, without many
dependices between patches. PHP isn't like that, especially with
Dmitry's engine changing patches.Yes, cherry picking is not as easy as people assume they are, because manychanges depend on each other and trunk has a fair quantity of these.I think trunk should be the starting point for 5.4; as to type hinting,I'm neutral as to the status quo.However, this is all orthogonal to this thread, what's important is thatwe agree on the formalities proposed so that we can proceed to thesematerial issues.--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] Re: Hold off 5.4 [RSS Feed]

Board footer

Moderator control

Enjoy the 17th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support