HEADS UP: 5.4 branch is open again View as Markdown

Hi Stats,

I'll work on the patch for strict session patch so that both
PHP 5.4 and 5.3 has the same functionality.

I've also added 2 new escape functions to pgsql in trunk
a while ago, pg_escape_literal()/pg_escape_identifier().
Is it okay to merge 5.4 branch also?

You mentioned it's okay for 5.4.1, but double checking.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

2012/3/2 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

When is cycle for 5.4.1 going to start?
I got a few traits-related patches waiting for it.

If you have some fixes, you can commit them now. Of course, the rules are as
always in stable branch - no BC breaking, no major features :)

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

that's totally off topic... but we have no idea yet when will be php
6, or whatsoever.

However next is in around a year :)

From the timelines I've seen floating around, I was under the impression
that the next one would be 5.5, followed by 5.6, etc.  PHP 6 is at least a
few years off according to every projection I've seen.

--Kris

Hi internals,

just a heads up. The PHP_5_4 branch is open for commits again.

• David

--

On a somehow related topic:
Now that we have 5.4 out, I have a question:
Do we know what will be the next major release?
If we want to follow the releaseprocess RFC, I think it would be nice to
think about whether we plan to roll out a major or a minor version next.
By the RFC, we can't do such changes to the language as we did with
5.2->5.3 or 5.3->5.4, because userland BC breaks aren't allowed.
So I can see two way to address this:
If we can agree upon the next version number beforehand, and we decide that
we will go with the major release (be that php 6 or 7, whatever), we don't
to do anything right now, we can branch the version from trunk/master, when
the time comes.
If we can't agree upon the next version number, or we agree upon that there
will be an 5.5 version, I think it would make sense to create a branch for
it ASAP, so there is place (trunk/master) for the approved but backward
incompatible changes, and people don't have to hold patches.
What do you think?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Yes, IF you're using a proper branching model. If you're just using it the
same way you'd use Subversion, which currently is the direction we seem to
be moving in, those advantages are mostly negated.

I agree that PHP 5.5 (and maybe even 5.6, etc) should come before PHP 6.
That being said, at some point a parallel development workflow might be
prudent IMHO, but even that would be a ways off I think.

--Kris

If we can agree upon the next version number beforehand, and we decide
that
we will go with the major release (be that php 6 or 7, whatever), we
don't
to do anything right now, we can branch the version from trunk/master,
when
the time comes.
If we can't agree upon the next version number, or we agree upon that
there
will be an 5.5 version, I think it would make sense to create a branch
for
it ASAP, so there is place (trunk/master) for the approved but
backward
incompatible changes, and people don't have to hold patches.
What do you think?

If I was in charge, and thankfully I'm not, I'd just create 5.5 and 6.0

If you have patches that don't break BC, put them in both. If you're
too busy to do both, put it in 6.0 Somebody will back-port or not,
based on their relative need/availability or not.

If it breaks BC, put it in 6.0

Or perhaps I misunderstand the tiny bit I thought I "got it" of the
point of using Git in the first place...

Branches and merges are supposed to be seamless, right???

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:

https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE