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:
- 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). - This branch is checked by RM to compile, pass unit tests
satisfactory, etc. and is released as 5.4.X RC1 - 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. - 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:
- Compilation failure on a major platform (Linux, Windows, Mac, maybe
some others at RM discretion) - Remotely exploitable security problem
- Bug that breaks a large piece of widely used functionality, effective
rendering it unusable (i.e. if somebody brokefopen()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
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.
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:
- 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).- This branch is checked by RM to compile, pass unit tests
satisfactory, etc. and is released as 5.4.X RC1- 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.- 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:
- Compilation failure on a major platform (Linux, Windows, Mac, maybe
some others at RM discretion)- Remotely exploitable security problem
- Bug that breaks a large piece of widely used functionality, effective
rendering it unusable (i.e. if somebody brokefopen()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
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,
KiallSent from my phone.
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:
- 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).- This branch is checked by RM to compile, pass unit tests
satisfactory, etc. and is released as 5.4.X RC1- 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.- 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:
- Compilation failure on a major platform (Linux, Windows, Mac, maybe
some others at RM discretion)- Remotely exploitable security problem
- Bug that breaks a large piece of widely used functionality, effective
rendering it unusable (i.e. if somebody brokefopen()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--
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
Stas,
On Mon, Apr 9, 2012 at 2:07 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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. EachI 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
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
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:
- RM creates PHP-5.4.x branch from PHP-5.4.
- Development continues on PHP-5.4 branch without any interaction with
PHP-5.4.x branch. - RM is allowed to commit directly to PHP-5.4.x.
- 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.
- 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. - 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
On Mon, Apr 9, 2012 at 2:57 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
release candidates. I mean, we're still planning on having multiple
release candidates before an actual release, right? If so, thenNot 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
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:
- 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).- This branch is checked by RM to compile, pass unit tests
satisfactory, etc. and is released as 5.4.X RC1- 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.- 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:
- Compilation failure on a major platform (Linux, Windows, Mac, maybe
some others at RM discretion)- Remotely exploitable security problem
- Bug that breaks a large piece of widely used functionality, effective
rendering it unusable (i.e. if somebody brokefopen()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/
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
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/
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
On Tue, Apr 10, 2012 at 3:46 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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--
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,
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
Pierre,
Kris,
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
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
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
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
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
hi,
2012/4/10 Johannes Schlüter johannes@schlueters.de:
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
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:
- 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
Op 17-4-2012 9:47, Hannes Magnusson schreef:
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:
- 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
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
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
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
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.
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
hi Stas,
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