On Tue, Jun 9, 2015 at 3:36 PM, Lior Kaplan <kaplanl...@gmail.com> wrote:
> On Tue, Jun 9, 2015 at 4:29 PM, Ferenc Kovacs <tyr...@php.net> wrote: > >> >> On Tue, Jun 9, 2015 at 3:23 PM, Lior Kaplan <kaplanl...@gmail.com> wrote: >> >>> Hi Guys, >>> >>> A quick question - I saw PHP-7.0.0 branch, should it be PHP-7.0 branch >>> (while master continues to 7.1). >>> >>> The PHP-7.0.0 should probably be for the RCs (while cherry picking from >>> PHP-7.0 as needed). If we have this branch too soon, you'll have a lot of >>> cherry picking to later later on. >>> >>> Kaplan >>> >> >> hi, >> cc-ing the internals list for visibility: >> >> the current plan is to not create a PHP-7.0 branch is until PHP-5.4 is >> EOLed, so we don't burden the average contributors yet another branch to >> merge upwards when pushing a change. >> PHP-7.0.0 will be only used by the RMs to tag the alpha/beta/RC versions >> from. >> yes, this means that until 5.4 is eoled and the PHP-7.0 branch is created >> changes targeting 7.1 have to sit in a clone or in a pull request. >> > > Thanks. > > The 7.1 changes are less of a concern, I just thought of the RM need to > merge from master to PHP-7.0.0 for each release instead of just working on > master directly. > Just my 2 cents. Of course, it's your decision... > > Kaplan > even for alpha/beta releaes you will need some commits which you don't want to have it in master: for example where you bump the version. without a release branch you would either have to commit then revert those version related changes in master and pollute master's history with that (this is what we used to do before started using the release branches approach) or you tag from a version not present in any remote branch (we did this in the past before we agreed to always push the release branches so if another RM has to take over a release for some reason it is easier to do so). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
