Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51144
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain metux.de from 82.165.128.25 cause and error)
Date: Fri, 31 Dec 2010 04:59:37 +0100
To: internals@lists.php.net
Message-ID: <20101231035937.GA18520@nibiru.local>
Reply-To: weigelt@metux.de
References: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com> <1290504719.2294.251.camel@guybrush> <AANLkTi=Lqki0nY2wgKRafTBGinPZZ+VLqkHagXzyJiMq@mail.gmail.com> <AANLkTimrd_5do=3PLB4w1jBNzzO0LBY4Jvqftjqeda7X@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTimrd_5do=3PLB4w1jBNzzO0LBY4Jvqftjqeda7X@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Subject: Re: [PHP-DEV] [RFC] Release Process
From: weigelt@metux.de (Enrico Weigelt)

* Ferenc Kovacs <info@tyrael.hu> wrote:

> You can't expect the users to switch to the new major version as soon as it
> comes out. They have to either migrate their codebase, and sadly they will
> wait(at least me and my collegues/friends do this) one or two micro/build
> version bump, usually the new major/major.minor version is stable enough.

ACK. One of my customers, a major ISP with millions of customers,
often sticks in older versions as newer ones tend to break many things.
Just had such a problem myself a few weeks ago: a minor update
(IIRC was from 5.3.2 to 5.3.3) broke virtually all of my web applications
(had to do lots of config adaptions to get it running again ;-o).

I got the strange feeling that php-devs don't care very much of long
term stability ;-p

It's more a problem of careful API/feature design than release cycling.
Once some feature or interface is in stable branch, it should stay there
w/o any disturbance at least until next *major* release.

> So if we want to support "equally" 2 major version concurrently, I can't see
> how can we make it through supporting 4 branches (oldmajor.last,
> oldmajor.current, newmajor.last, newmajor.current)
> 
> or we can make "unequal" or "favored" branches:
> - either an early adopter vs lts sytem like ubuntu does, but they have 4
> supported version at a time also
> https://wiki.ubuntu.com/LTS
> but I don't know how to mix LTS and php, because they release "shared
> nothing" versions, while the php versions does share a common codebase
> through their major version, so we can't plan beforehand that what version
> will be the nextlts before getting there like the ubuntu guys can. :/

Why not using a branch hierachy ?

* new major branch is forked from latest release tag when compatibility
  breaks will occour (properly planned and only done if *necessary*,
  eg. like 4.x -> 5.x).
* for each minor release, a separate branch is forked on the latest
  stable tag.
* bugs in a minor releases are fixed in these branches and micro
  releases tagged out from there.
* canonical versioning scheme: A.B.C (the 4th digit is reserved for
  distros / downstreams)
* all issues (bugfixes, features, etc) are done in their own per-issue
  branches, which get rebased to their parent branch before merging back.


Scenario A: bugfixing.

-> found a bug in 5.3.4, reporting as bug# 12345
-> forking a branch bugfix_5.3.4_12345 from release-5.3.4
-> fixing the bug, testing until everything's fine
-> rebasing to latest php-5.3 branch and maybe retest.
-> submit my bugfix branch for review, until aggreed to be fine
-> rebase to latest php-5.3 again and merge into it
-> tag a new release from that branch
-> rebase to to latest master branch (that will become 5.4),
   test again and merge if still applicable there

Scenario B: new feature

-> inventing some super-new feature, which will take a while to 
   be stableized
-> fork from latest stable release or master branch (whatever seems
   applicable, on when the feature might get into mainline)
-> do development here, possible rework multiple times
-> frequently rebase to new releases or master branch
-> plan into which release the feature will get in
-> when properly reviewed/tested/accepted, rebased to latest master
   and merge into it



cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------