On 28 August 2014 19:55, Julien Pauli <jpa...@php.net> wrote: > Hello, > > We all know 5.3 is now EOL. > > Looking at git branches, 5.0, 5.1 and 5.2 still have their respective > main branches (which is all right and good). > > However, they dont have their release branch references (5.1.1 , 5.1.2 > etc...) , however they still show their own release tags, which is > also all right. > > As a reminder, release *branches* (not the tags) are used by the RMs > to actually release the version. > RMs branch from the main repo into a release branch, and apply their > RM-managing-stuff commits as well as backport eventual commits from > the main branch, for CVEs, for example. > > Those release branches are here just for the release, and are no > longer needed at all after the release has been released, because > every release owns its own final git tag.
Based on this, it doesn't seem like there's any point in keeping the branches at all after the tag is created. I would take this proposal a step further and suggest a policy of deleting the previous release branch when a new release is made (i.e. when 5.6.1 is tagged, the 5.6.0 branch would be deleted). The workflow described dictates that no changes should be made to a branch after its corresponding tag is created, and github provides a decent, universally accessible and familiar UI for browsing the code of a particular tag. I would be in favour of keeping hold of a branch until the following release is created (rather than deleting it when that release is made) as "emergency" releases - for example when a major security flaw is discovered after a release - could be facilitated by keeping hold of the old branch, although even this reasoning is highly questionable. I really don't see the need to keep any release branches hanging around cluttering up the place. Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
