Cleaning 5.3 git branches ?

But, thoughts to clean release branches from our git for EOL PHP
versions, like 5.3 ?
Tag references should be enough for history, IMHO

It’s my understanding that a tag is merely an immutable branch (or a branch is merely a mutable tag), so I’d be completely in favour of this.

--
Andrea Faulds
http://ajf.me/

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.

The tag is written lowercased (php-5.5.4) and the branch is written
uppercased (PHP-5.5.4).

What I suggest, is removing those branch references from our git, for
EOL versions of PHP.
This is done for PHP<=5.2 (but that was before the move to git) , but
PHP5.3 release branches are still referenced.

Of course references in git are very light things, but they tend to
pollute the references.
For example , browsing our branches in the github mirror select box is
a pain nowadays.
Same for git command line autocompletion that shows every remote
branches, or the "git branch --all" command , and its friends.

I already sent a mail, few months ago, to clean the branches we dont
use any more.
Some argued that for history, they should be kept referenced.

But, thoughts to clean release branches from our git for EOL PHP
versions, like 5.3 ?
Tag references should be enough for history, IMHO

Julien.P

--

Hi,

just my two cents:
I think RMs should remove the PHP-X.Y.Z branches after a release is made
(as you mentioned we already have a tag, and after a release is made, we
will never continue development/re-tag, so there is no reason to preserve
the branch).
I also think that feature/work branches should be deleted after they are
merged (we still have phpng and str_size_and_int64 for example).
But I don't see much point in deleting the release branches (PHP-X.Y) even
for eol'ed version.
The number of those branches are pretty small, sometimes we leave some
commits in the release branch, which doesn't made into the last release tag
(https://github.com/php/php-src/compare/PHP-5.3.29...PHP-5.3), plus in the
past we had precedence(PHP-5.2), when we had to make additional releases
after the originally planned EOL release, which if using this policy would
be a bit messy(you either don't merge those commits upward, or you have to
recreate the previously deleted PHP-X.Y branch first, or create a PHP-X.Y.Z
branch from the last tag, push there, and merge and tag from that branch).

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

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

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.

For those branches we never had release branches, so there is no wonder
they don't exist.

I would favor to create a php-src-historic.git repo (or similar) which
receives all old branches. With PHP 4 and 5.<=3 there this also might
make the initial clone a tiny bit smaller while keeping all history for
archeologists.

johannes

I already sent a mail, few months ago, to clean the branches we dont
use any more. Some argued that for history, they should be kept
referenced.

As they are so light weight, there is no reason to remove them. Please
keep them. I still occasionally build against the PHP-5.2 branch f.e.

cheers,
Derick