[PHP-DEV] release process with git

Hi!

5.4.1 will be the first release we're releasing using our new git setup.
I would like to refine a process that we used to have for releases and
make small tweaks hopefully to allow us more predictable release
schedule and faster releases.
What I am proposing is the following:
1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
assume we'll usually release on Thursday and count back from that).
2. This branch is checked by RM to compile, pass unit tests
satisfactory, etc. and is released as 5.4.X RC1
3. In two weeks, if no critical errors is found in RC1, the same branch
is released as 5.4.X. If any critical errors are found, RM cherry-pick
fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks
after no criticial bugs are in 5.4.X branch.
4. In two more weeks, 5.4.(X+1) starts, provided we have changes from
5.4.X. If not, it is postponed by 2 weeks.

It is somewhat different from what we did before as we never disallow
committing into 5.4 and never allow (direct) committing into 5.4.X. This
also means we will be releasing 2-weeks-old code (or maybe older), i.e.
we will frequently be releasing code which has known (and fixed in other
branch) bugs.

This will also mean we will have to define what constitutes critical
error, and maybe raise the bar a bit. I would like to propose the
following criteria for critical error:
1. Compilation failure on a major platform (Linux, Windows, Mac, maybe
some others at RM discretion)
2. Remotely exploitable security problem
3. Bug that breaks a large piece of widely used functionality, effective
rendering it unusable (i.e. if somebody broke fopen() and it always
returned false).
Other things may be added on case-by-case basis but this will be the
guidelines. All other changes go into the next release.

I think doing it this way will allow us to have 5.4.X releases monthly
as we planned in the release RFC. This will also mean that there would
be almost constant lag between committing regular fix and releasing it,
which may be larger than we had before. I think it won't be too bad if
we had regular monthly releases.

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

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

This is a very similar process to what OpenStack uses, it seems to work
well for them.

They have a few guys on freenode in #openstack-infra that have shown
themselves more than willing to go into detail about their setup and its
pro/con's..

It would be worth asking them for their experience...

Thanks,
Kiall

Sent from my phone.
On Apr 9, 2012 7:54 a.m., "Stas Malyshev" <[email protected]> wrote:

> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.
> I would like to refine a process that we used to have for releases and
> make small tweaks hopefully to allow us more predictable release
> schedule and faster releases.
> What I am proposing is the following:
> 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
> done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
> assume we'll usually release on Thursday and count back from that).
> 2. This branch is checked by RM to compile, pass unit tests
> satisfactory, etc. and is released as 5.4.X RC1
> 3. In two weeks, if no critical errors is found in RC1, the same branch
> is released as 5.4.X. If any critical errors are found, RM cherry-pick
> fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks
> after no criticial bugs are in 5.4.X branch.
> 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from
> 5.4.X. If not, it is postponed by 2 weeks.
>
> It is somewhat different from what we did before as we never disallow
> committing into 5.4 and never allow (direct) committing into 5.4.X. This
> also means we will be releasing 2-weeks-old code (or maybe older), i.e.
> we will frequently be releasing code which has known (and fixed in other
> branch) bugs.
>
> This will also mean we will have to define what constitutes critical
> error, and maybe raise the bar a bit. I would like to propose the
> following criteria for critical error:
> 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe
> some others at RM discretion)
> 2. Remotely exploitable security problem
> 3. Bug that breaks a large piece of widely used functionality, effective
> rendering it unusable (i.e. if somebody broke fopen() and it always
> returned false).
> Other things may be added on case-by-case basis but this will be the
> guidelines. All other changes go into the next release.
>
> I think doing it this way will allow us to have 5.4.X releases monthly
> as we planned in the release RFC. This will also mean that there would
> be almost constant lag between committing regular fix and releasing it,
> which may be larger than we had before. I think it won't be too bad if
> we had regular monthly releases.
>
> Comments?
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Mon, Apr 9, 2012 at 3:26 AM, Kiall Mac Innes <[email protected]> wrote:

> This is a very similar process to what OpenStack uses, it seems to work
> well for them.
>
> They have a few guys on freenode in #openstack-infra that have shown
> themselves more than willing to go into detail about their setup and its
> pro/con's..
>
> It would be worth asking them for their experience...
>
> Thanks,
> Kiall
>
> Sent from my phone.
> On Apr 9, 2012 7:54 a.m., "Stas Malyshev" <[email protected]> wrote:
>
> > Hi!
> >
> > 5.4.1 will be the first release we're releasing using our new git setup.
> > I would like to refine a process that we used to have for releases and
> > make small tweaks hopefully to allow us more predictable release
> > schedule and faster releases.
> > What I am proposing is the following:
> > 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
> > done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
> > assume we'll usually release on Thursday and count back from that).
> > 2. This branch is checked by RM to compile, pass unit tests
> > satisfactory, etc. and is released as 5.4.X RC1
> > 3. In two weeks, if no critical errors is found in RC1, the same branch
> > is released as 5.4.X. If any critical errors are found, RM cherry-pick
> > fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks
> > after no criticial bugs are in 5.4.X branch.
> > 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from
> > 5.4.X. If not, it is postponed by 2 weeks.
> >
> > It is somewhat different from what we did before as we never disallow
> > committing into 5.4 and never allow (direct) committing into 5.4.X. This
> > also means we will be releasing 2-weeks-old code (or maybe older), i.e.
> > we will frequently be releasing code which has known (and fixed in other
> > branch) bugs.
> >
> > This will also mean we will have to define what constitutes critical
> > error, and maybe raise the bar a bit. I would like to propose the
> > following criteria for critical error:
> > 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe
> > some others at RM discretion)
> > 2. Remotely exploitable security problem
> > 3. Bug that breaks a large piece of widely used functionality, effective
> > rendering it unusable (i.e. if somebody broke fopen() and it always
> > returned false).
> > Other things may be added on case-by-case basis but this will be the
> > guidelines. All other changes go into the next release.
> >
> > I think doing it this way will allow us to have 5.4.X releases monthly
> > as we planned in the release RFC. This will also mean that there would
> > be almost constant lag between committing regular fix and releasing it,
> > which may be larger than we had before. I think it won't be too bad if
> > we had regular monthly releases.
> >
> > Comments?
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Yeah this also sounds similar to Gitflow, as this would basically be our
version of a "Release-x.xx" branch. I would suggest allowing commits on
that branch, but *only* if they're bugfixes or minor housekeeping. Each
commit would basically be the equivalent of a release candidate (i.e.
initial branch commit would be RC1, next commit RC2, etc).

Then when it's time to pull the trigger, the final commit on that branch
will be the actual release. Then merge that branch back into PHP-5.4. By
doing that last step, parallel ongoing development on the next 5.4 release
can continue without restriction. Any last-minute bugfixes from the
PHP-5.4.X branch would be merged-in so everything would remain up-to-date.

--Kris

Hi!

> version of a "Release-x.xx" branch. I would suggest allowing commits on
> that branch, but *only* if they're bugfixes or minor housekeeping. Each

I don't want to do this, because this would very quickly lead us back to
old chaotic situation where people commit stuff at the last moment and
it's not properly tested. I prefer to have defined merge points.

> commit would basically be the equivalent of a release candidate (i.e.
> initial branch commit would be RC1, next commit RC2, etc).
>
> Then when it's time to pull the trigger, the final commit on that branch
> will be the actual release. Then merge that branch back into PHP-5.4.

That's what I don't want to do. I don't want people to be
live-committing into release branch and then merge it back to dev
branch. I want release branch be clean and frozen as much as possible,
and people committing to dev branch as needed. No last-minute bugfixes
either unless it's a bug that absolutely breaks the release - otherwise
it'll be released in a month, most bugs can wait for a month without any
problem, given that they waited till now.

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

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

Stas,

On Mon, Apr 9, 2012 at 2:07 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > version of a "Release-x.xx" branch. I would suggest allowing commits on
> > that branch, but *only* if they're bugfixes or minor housekeeping. Each
>
> I don't want to do this, because this would very quickly lead us back to
> old chaotic situation where people commit stuff at the last moment and
> it's not properly tested. I prefer to have defined merge points.
>
> > commit would basically be the equivalent of a release candidate (i.e.
> > initial branch commit would be RC1, next commit RC2, etc).
> >
> > Then when it's time to pull the trigger, the final commit on that branch
> > will be the actual release. Then merge that branch back into PHP-5.4.
>
> That's what I don't want to do. I don't want people to be
> live-committing into release branch and then merge it back to dev
> branch. I want release branch be clean and frozen as much as possible,
> and people committing to dev branch as needed. No last-minute bugfixes
> either unless it's a bug that absolutely breaks the release - otherwise
> it'll be released in a month, most bugs can wait for a month without any
> problem, given that they waited till now.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>

What I'm referring to is the same kind of bugfixes/etc that go into new
release candidates. I mean, we're still planning on having multiple
release candidates before an actual release, right? If so, then obviously
we'll need a way to commit those changes. If they're not made on the RC
branch, then where were you thinking they should go, and how would we then
apply those bugfixes to the 5.4 trunk if not through a merge?

--Kris

On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig <[email protected]> wrote:
>
> What I'm referring to is the same kind of bugfixes/etc that go into new
> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then obviously
> we'll need a way to commit those changes. If they're not made on the RC
> branch, then where were you thinking they should go, and how would we then
> apply those bugfixes to the 5.4 trunk if not through a merge?


Referring again to how openstack manages this (because I personally feel
they have nailed it)..

Any commit that should be applied to the RC should also be applied to
master/trunk, right? So - Why not commit it to master/trunk and nominate it
for inclusion in the release. This allows a release manager to look at the
bug, the fix, and the implications of of the fix before the fix lands in
the RC.

Once a commit has been made to master/trunk.. That fix can be cherry-picked
into the RC if it's deemed suitable.

Thanks,
Kiall

On 04/08/2012 11:54 PM, Stas Malyshev wrote:
> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.
> I would like to refine a process that we used to have for releases and
> make small tweaks hopefully to allow us more predictable release
> schedule and faster releases.
> What I am proposing is the following:
> 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
> done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
> assume we'll usually release on Thursday and count back from that).
> 2. This branch is checked by RM to compile, pass unit tests
> satisfactory, etc. and is released as 5.4.X RC1
> 3. In two weeks, if no critical errors is found in RC1, the same branch
> is released as 5.4.X. If any critical errors are found, RM cherry-pick
> fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks
> after no criticial bugs are in 5.4.X branch.
> 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from
> 5.4.X. If not, it is postponed by 2 weeks.
>
> It is somewhat different from what we did before as we never disallow
> committing into 5.4 and never allow (direct) committing into 5.4.X. This
> also means we will be releasing 2-weeks-old code (or maybe older), i.e.
> we will frequently be releasing code which has known (and fixed in other
> branch) bugs.
>
> This will also mean we will have to define what constitutes critical
> error, and maybe raise the bar a bit. I would like to propose the
> following criteria for critical error:
> 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe
> some others at RM discretion)
> 2. Remotely exploitable security problem
> 3. Bug that breaks a large piece of widely used functionality, effective
> rendering it unusable (i.e. if somebody broke fopen() and it always
> returned false).
> Other things may be added on case-by-case basis but this will be the
> guidelines. All other changes go into the next release.
>
> I think doing it this way will allow us to have 5.4.X releases monthly
> as we planned in the release RFC. This will also mean that there would
> be almost constant lag between committing regular fix and releasing it,
> which may be larger than we had before. I think it won't be too bad if
> we had regular monthly releases.
>
> Comments?

Stas,

I'm fine with this.

I would like to see clarity on when fixes have been merged to the RC
branch (git emails are still a bit hard to grok). It would help to
have early communication about fixes you have decided against so we
can argue their merits and so we don't assume you are planning to pick
them up.

Chris

--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

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

On Mon, Apr 9, 2012 at 2:33 PM, Kiall Mac Innes <[email protected]> wrote:

> On Mon, Apr 9, 2012 at 10:27 PM, Kris Craig <[email protected]> wrote:
>>
>> What I'm referring to is the same kind of bugfixes/etc that go into new
>> release candidates. I mean, we're still planning on having multiple
>> release candidates before an actual release, right? If so, then obviously
>> we'll need a way to commit those changes. If they're not made on the RC
>> branch, then where were you thinking they should go, and how would we then
>> apply those bugfixes to the 5.4 trunk if not through a merge?
>
>
> Referring again to how openstack manages this (because I personally feel
> they have nailed it)..
>
> Any commit that should be applied to the RC should also be applied to
> master/trunk, right? So - Why not commit it to master/trunk and nominate it
> for inclusion in the release. This allows a release manager to look at the
> bug, the fix, and the implications of of the fix before the fix lands in
> the RC.
>
> Once a commit has been made to master/trunk.. That fix can be
> cherry-picked into the RC if it's deemed suitable.
>

That approach would also work, so long as the RM doesn't mind having to
cherry-pick through different commits, making sure they're not based off of
non-included commits that would cause conflicts, etc. Git merging
essentially does the bulk of this grunt work for you; but the downside, as
Stas pointed out, is that people would then wind-up posting unnecessary
commits because there would be no manual filtering.

Hmm so how about we consider a third option? It sounds like what we need
is a bridge so that bugfixes can be quarantined yet still cherry-picked by
the RM without the added burden of code conflicts being introduced from
trunk.

So how about this:


1. RM creates PHP-5.4.x branch from PHP-5.4.
2. Development continues on PHP-5.4 branch without any interaction with
PHP-5.4.x branch.
3. RM is allowed to commit directly to PHP-5.4.x.
4. Anybody else who wants to propose a bugfix will create a new branch
based off of PHP-5.4.x.
- For example: git checkout -b Bugfix-Some_Bugfix_Title PHP-5.4.x.
5. Once commit(s) on Bugfix branch are made, developer merges the bugfix
into PHP-5.4 trunk branch and asks the RM (i.e. "nominates" it, as you put
it) to merge it into the PHP-5.4.x release branch as well.
6. RM can decide whether or not to merge it in. Because the branch was
based off of the release branch as opposed to trunk, it's considerably less
likely that any conflicts will emerge should the RM decide to merge it in.
If s/he doesn't merge it in, the changes have already been merged into the
trunk branch so at very least they'll be there for the next release.

This approach should address everyone's concerns while taking advantage of
Git's branching functionality, which was designed precisely with situations
such as this in mind. The RM filter remains but the manual workload and
potential for human error are both dramatically reduced.

--Kris


> Thanks,
> Kiall
>

Hi!

> release candidates. I mean, we're still planning on having multiple
> release candidates before an actual release, right? If so, then

Not if we can avoid it. If we don't have critical bugs in RC1, we
release it.

> obviously we'll need a way to commit those changes. If they're not made
> on the RC branch, then where were you thinking they should go, and how
> would we then apply those bugfixes to the 5.4 trunk if not through a merge?

If you have bugfix for 5.4, commit it into 5.4. If it's critical for
current release, it will be pulled by RM into the release, otherwise he
automatically becomes part of the next release.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > release candidates. I mean, we're still planning on having multiple
> > release candidates before an actual release, right? If so, then
>
> Not if we can avoid it. If we don't have critical bugs in RC1, we
> release it.
>
> > obviously we'll need a way to commit those changes. If they're not made
> > on the RC branch, then where were you thinking they should go, and how
> > would we then apply those bugfixes to the 5.4 trunk if not through a
> merge?
>
> If you have bugfix for 5.4, commit it into 5.4. If it's critical for
> current release, it will be pulled by RM into the release, otherwise he
> automatically becomes part of the next release.
>

My concern is that merge conflicts can occur when cherry-picking in this
manner. It's just generally not a "best practices" approach when using Git
IMHO. The appropriate way to do this would be to have these bugfixes
pushed as separate branches based off of the release branch, then the RM
chooses whether or not to merge each one back into the release branch.
This takes advantage of Git's built-in branching/merging functionality
without the need for manual cherry-picking. These fixes can then be merged
back into trunk, so the end result is the same but with far less manual
work and less potential for human error.

--Kris


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

Hi!

> My concern is that merge conflicts can occur when cherry-picking in this
> manner. It's just generally not a "best practices" approach when using

Which merge conflicts? Diff between 5.4 and 5.4.X will never be big
enough to have any conflicts. It's just 2 weeks of stable version code.

> cherry-picking. These fixes can then be merged back into trunk, so the
> end result is the same but with far less manual work and less potential
> for human error.

I'm OK with some manual work, we won't have that much (only for critical
bugs). I don't want to merge release branch into dev branch since it
contains release-only stuff that doesn't have to be in dev branch, and I
want merges to be one direction only - from dev to release, I don't want
people putting code into release branch after RC1 unless it is an
emergency. Otherwise we get much slower release cycles since each change
basically sets us back 2 weeks.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

Hi!

> I would like to see clarity on when fixes have been merged to the RC
> branch (git emails are still a bit hard to grok). It would help to
> have early communication about fixes you have decided against so we
> can argue their merits and so we don't assume you are planning to pick
> them up.

So this is the main point I want to change. There will be no fixes
"decided for" and "decided against". Once RC1 is out, this is by default
the release, and all the fixes since this point go into version X+1. The
only exception - and I can't emphasize enough that I want it to be
exception, not a usual occurrence - if we have a critical issue in RC1.
So by default no fixes are rejected and no fixes are merged - once RC1
is out, fixes are presumed to be in X+1 version. Unless you know this is
a critical bug (meaning, there's absolutely no point releasing PHP with
it as either one could not use it - e.g. it does not compile - or nobody
in his sane mind would use it - e.g. remote security hole) there would
be no point deciding or arguing about it.
Again, this is a change from what we did before, not a big one, but as
you can see it requires some mindset shift. I think it will improve our
release process and will make us able to release quick and quality versions.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

On 4/9/12 3:21 PM, Stas Malyshev wrote:
> Hi!
>
>> I would like to see clarity on when fixes have been merged to the RC
>> branch (git emails are still a bit hard to grok). It would help to
>> have early communication about fixes you have decided against so we
>> can argue their merits and so we don't assume you are planning to pick
>> them up.
>
> So this is the main point I want to change. There will be no fixes
> "decided for" and "decided against". Once RC1 is out, this is by default
> the release, and all the fixes since this point go into version X+1. The
> only exception - and I can't emphasize enough that I want it to be
> exception, not a usual occurrence - if we have a critical issue in RC1.
> So by default no fixes are rejected and no fixes are merged - once RC1
> is out, fixes are presumed to be in X+1 version. Unless you know this is
> a critical bug (meaning, there's absolutely no point releasing PHP with
> it as either one could not use it - e.g. it does not compile - or nobody
> in his sane mind would use it - e.g. remote security hole) there would
> be no point deciding or arguing about it.
> Again, this is a change from what we did before, not a big one, but as
> you can see it requires some mindset shift. I think it will improve our
> release process and will make us able to release quick and quality versions.

I think my main point still stands: if the git emails are too obscure to
follow, let us know what goes in via email to internals.

Do you want to bring the NEWS updating process into this discussion?

Chris

--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/

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

On Sun, 2012-04-08 at 23:54 -0700, Stas Malyshev wrote:
> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.

As will 5.3.11.

> I would like to refine a process that we used to have for releases and
> make small tweaks hopefully to allow us more predictable release
> schedule and faster releases.
> What I am proposing is the following:
[...]

For 5.3.11+ my base assumption is that every bug in there exists for a
few years already (we don't add new features or such, do we? ;-) ).
Going from there I agree that fixes made during the release cycle can
easily wait for the next release. So the approach is fine.


For 5.3.11RC2 I'm currently looking at merging (cherry-picking)

0f180a6 - Fixed bug in new stream_get_line() when using NUL as a delimiter.
(This is a regression from 5.3.10)
9bf8cd4 - Fixed bug #61650 (ini parser crashes when using ${xxxx} ini variables (without apache2))
(Crash fix)
ca58cd0 - Cherry-pick 4cc74767 Headers: forbid \r and \n also after \0, allow CRLF followed by HT or SP and forbid \0. See bug #60227.
(Security related)
55a6f3a - - update to openssl 0.9.8u
(Readme change for Win distribution, no code change)
0e53ac4 - - Updated to version 2012.3 (2012c)
(current timezone data)
8449e0c - Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)
(compilation issue)

johannes



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

hi,

2012/4/10 Johannes Schlüter <[email protected]>:

>  0f180a6 - Fixed bug in new stream_get_line() when using NUL as a delimiter.
>    (This is a regression from 5.3.10)
>  9bf8cd4 - Fixed bug #61650 (ini parser crashes when using ${xxxx} ini variables (without apache2))
>    (Crash fix)
>  ca58cd0 - Cherry-pick 4cc74767  Headers: forbid \r and \n also after \0, allow CRLF followed by HT or SP and forbid \0. See bug #60227.
>    (Security related)
>  55a6f3a - - update to openssl 0.9.8u
>    (Readme change for Win distribution, no code change)
>  0e53ac4 - - Updated to version 2012.3 (2012c)
>    (current timezone data)
>  8449e0c - Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)
>     (compilation issue)

The Fileinfo fix (in 5.3.11 and 5.4.1) is missing as well as the
..gitattributes addtions to fix the LF issues (all branches).


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

Hi!

> I think my main point still stands: if the git emails are too obscure to
> follow, let us know what goes in via email to internals.
>
> Do you want to bring the NEWS updating process into this discussion?

Sure, though that would be another discussion IMHO. In this discussion,
I just wanted to see if there are any objections to this "clean release"
model.


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

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

On Tue, Apr 10, 2012 at 3:46 PM, Stas Malyshev <[email protected]>wrote:

> Hi!
>
> > I think my main point still stands: if the git emails are too obscure to
> > follow, let us know what goes in via email to internals.
> >
> > Do you want to bring the NEWS updating process into this discussion?
>
> Sure, though that would be another discussion IMHO. In this discussion,
> I just wanted to see if there are any objections to this "clean release"
> model.
>
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Given the number of RCs we've seen in the past, I remain skeptical that
your approach will prove sustainable. But I'd say let's just try it and
see how it goes.

--Kris

Kris,

On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig <[email protected]> wrote:

> Given the number of RCs we've seen in the past, I remain skeptical that
> your approach will prove sustainable.  But I'd say let's just try it and
> see how it goes.

Saying that is totally ignoring the main point in the new way: Very
limited amount of changes allowed after the 1st RCs, or between two
releases.

The insane amount of changes is what made impossible to release
quickly in the past, like in 5.3 now.

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

Pierre,

On Tue, Apr 10, 2012 at 10:42 PM, Pierre Joye <[email protected]> wrote:

> Kris,
>
> On Wed, Apr 11, 2012 at 1:13 AM, Kris Craig <[email protected]> wrote:
>
> > Given the number of RCs we've seen in the past, I remain skeptical that
> > your approach will prove sustainable. But I'd say let's just try it and
> > see how it goes.
>
> Saying that is totally ignoring the main point in the new way: Very
> limited amount of changes allowed after the 1st RCs, or between two
> releases.
>
> The insane amount of changes is what made impossible to release
> quickly in the past, like in 5.3 now.
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>

True true. But old patterns have a funny way of reasserting themselves. I
hope you and Stas are right; but, as they say, I'll believe it when I see
it. ;)

--Kris

On 04/10/2012 03:46 PM, Stas Malyshev wrote:
> Hi!
>
>> I think my main point still stands: if the git emails are too obscure to
>> follow, let us know what goes in via email to internals.
>>
>> Do you want to bring the NEWS updating process into this discussion?
>
> Sure, though that would be another discussion IMHO. In this discussion,
> I just wanted to see if there are any objections to this "clean release"
> model.
>
>

Stas,

Currently is seems the PHP-5.4 branch is building version 5.4.1RC1-dev
while the PHP-5.4.1 branch builds version 5.4.1RC2.

I think that once PHP-5.4.1 was branched, then PHP-5.4 should have
become 5.4.2-dev.

Chris

--
christopher.jones@oracle.com
http://twitter.com/#!/ghrd

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

Hi!

> I think that once PHP-5.4.1 was branched, then PHP-5.4 should have
> become 5.4.2-dev.

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

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

On 04/16/2012 01:12 PM, Stas Malyshev wrote:
> Hi!
>
>> I think that once PHP-5.4.1 was branched, then PHP-5.4 should have
>> become 5.4.2-dev.
>
> You're right.

As an exercise, I submitted a pull request fixing this.

Chris

--
christopher.jones@oracle.com
http://twitter.com/#!/ghrd

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

On Mon, Apr 9, 2012 at 08:54, Stas Malyshev <[email protected]> wrote:
> Hi!
>
> 5.4.1 will be the first release we're releasing using our new git setup.
> I would like to refine a process that we used to have for releases and
> make small tweaks hopefully to allow us more predictable release
> schedule and faster releases.
> What I am proposing is the following:
> 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
> done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
> assume we'll usually release on Thursday and count back from that).

(tiny hijacking).

The whole point of releasing on Thursdays is so sysadmins have the
chance to update their servers in the event of known security problems
"before the weekend".
This point however becomes void when we release late Thursdays evening
American time, and we could just as well release on Saturday nights as
noone in Europe will be able to update their servers, and the
Americans will probably not be updating theirs either when they notice
the release Fridays after lunch.

Even keeping in mind most sysadmins probably use distro packages,
these packages won't be built by their maintainers late Fridays and
therefore never rolled out to the public until after the weekend.

If we however switch to Tuesdays we atleast give the sysadmins (and
package builders) a fighting chance of not needing to decide between
running possibly very unsecure environment over the weekend or risk
breaking the production environment due to unforeseen mishaps.

Could we swap the release day to Tuesday?
Or atleast very very very very early morning Thursdays?

-Hannes

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

Op 17-4-2012 9:47, Hannes Magnusson schreef:
> On Mon, Apr 9, 2012 at 08:54, Stas Malyshev<smalysh[email protected]> wrote:
>> Hi!
>>
>> 5.4.1 will be the first release we're releasing using our new git setup.
>> I would like to refine a process that we used to have for releases and
>> make small tweaks hopefully to allow us more predictable release
>> schedule and faster releases.
>> What I am proposing is the following:
>> 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is
>> done on Monday/Tuesday (days can be tweaked back&forth a bit, but I
>> assume we'll usually release on Thursday and count back from that).
> (tiny hijacking).
>
> The whole point of releasing on Thursdays is so sysadmins have the
> chance to update their servers in the event of known security problems
> "before the weekend".
> This point however becomes void when we release late Thursdays evening
> American time, and we could just as well release on Saturday nights as
> noone in Europe will be able to update their servers, and the
> Americans will probably not be updating theirs either when they notice
> the release Fridays after lunch.
>
> Even keeping in mind most sysadmins probably use distro packages,
> these packages won't be built by their maintainers late Fridays and
> therefore never rolled out to the public until after the weekend.
>
> If we however switch to Tuesdays we atleast give the sysadmins (and
> package builders) a fighting chance of not needing to decide between
> running possibly very unsecure environment over the weekend or risk
> breaking the production environment due to unforeseen mishaps.
>
> Could we swap the release day to Tuesday?
> Or atleast very very very very early morning Thursdays?
>
> -Hannes
>

Sounds like facilitating wrong security protocols to me. In this
365/24/7 environment, sysadmins should be willing and able to patch, fix
and secure systems at any time. Weekend should be no excuse.

Bas

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

On 17.04.12 10:24, Bas van Beek wrote:
> Sounds like facilitating wrong security protocols to me. In this
> 365/24/7 environment, sysadmins should be willing and able to patch, fix
> and secure systems at any time. Weekend should be no excuse.

There are a lot of (very serious) shops out there without a 24/7 ops
schedule. Let's not hurt them without a solid reason.

- Martin

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

Hi!

> The whole point of releasing on Thursdays is so sysadmins have the
> chance to update their servers in the event of known security problems
> "before the weekend".
> This point however becomes void when we release late Thursdays evening
> American time, and we could just as well release on Saturday nights as
> noone in Europe will be able to update their servers, and the
> Americans will probably not be updating theirs either when they notice
> the release Fridays after lunch.

I tag and package Wednesday evening US Pacific time. I can change the
Wednesday part, but not the "evening US Pacific" part, at least not
until I move to a different timezone. If current schedule is not
satisfactory, I have nothing against moving it to Tuesday. Pretty much
any day is OK with me, so let's see what people think.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

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

On 2012-04-17, Stas Malyshev <[email protected]> wrote:
> Hi!
>
>> The whole point of releasing on Thursdays is so sysadmins have the
>> chance to update their servers in the event of known security problems
>> "before the weekend".
>> This point however becomes void when we release late Thursdays evening
>> American time, and we could just as well release on Saturday nights as
>> noone in Europe will be able to update their servers, and the
>> Americans will probably not be updating theirs either when they notice
>> the release Fridays after lunch.
>
> I tag and package Wednesday evening US Pacific time. I can change the
> Wednesday part, but not the "evening US Pacific" part, at least not
> until I move to a different timezone. If current schedule is not
> satisfactory, I have nothing against moving it to Tuesday. Pretty much
> any day is OK with me, so let's see what people think.

Yes at the moment we have the problem that:

Stas tags Wednesday evening US Pacific time
Stefan builds Thursday during the day US Pacific time
David announces after all this is done which is Thursday evening EU time
sometimes it becomes so late that I can only do it friday morning.


So if we want to release Thursday, then windows builds need to be done one
Wednesday.

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

Hi!

> Stas tags Wednesday evening US Pacific time
> Stefan builds Thursday during the day US Pacific time
> David announces after all this is done which is Thursday evening EU time
> sometimes it becomes so late that I can only do it friday morning.
>
>
> So if we want to release Thursday, then windows builds need to be done one
> Wednesday.

OK, I can tag on Tuesday instead, will it make things better? Let's try
it with 5.4.1.

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

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

hi Stas,

On Tue, Apr 17, 2012 at 10:19 PM, Stas Malyshev <[email protected]> wrote:

>> So if we want to release Thursday, then windows builds need to be done one
>> Wednesday.
>
> OK, I can tag on Tuesday instead, will it make things better? Let's try
> it with 5.4.1.

It is important to keep in mind (we did not for the last ones) that
RCs should be tagged two days before their release, ideally. The
reason is to avoid to release a broken release, which totally defeat
the goals of a RC and delay the final release. This is part of the
release process RFC btw,

For the final release, given that we stick to the golden release
principle, it is not necessary. Tuesday should be enough so we have
enough time to get the mirrors updated, announces written, and all the
other things.

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

On Tue, April 17, 2012 3:34 am, Martin Jansen wrote:
> On 17.04.12 10:24, Bas van Beek wrote:
>> Sounds like facilitating wrong security protocols to me. In this
>> 365/24/7 environment, sysadmins should be willing and able to patch,
>> fix
>> and secure systems at any time. Weekend should be no excuse.

Willing to? Yes.

Happy about it? No.

Deciding PHP is a PITA because it keeps making them work on weekends?
Bad Idea.

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



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