Re: [RFC] Release Process

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