# Cleaning 5.3 git branches ?

- Thread: https://externals.io/message/76924
- Original archive: https://news-web.php.net/php.internals/76924
- Started by Julien Pauli on 2014-08-28T18:55:28+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #76924 — Julien Pauli — 2014-08-28T18:55:28+00:00

URL: https://externals.io/message/76924#76924

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

---

## #76925 — Andrea Faulds — 2014-08-28T19:13:37+00:00

URL: https://externals.io/message/76924#76925 · In reply to: #76924

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

---

## #76927 — Ferenc Kovacs — 2014-08-28T20:04:35+00:00

URL: https://externals.io/message/76924#76927 · In reply to: #76924

> 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

---

## #76928 — Chris Wright — 2014-08-28T20:07:10+00:00

URL: https://externals.io/message/76924#76928 · In reply to: #76924

> 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

---

## #76933 — johannes@schlueters.de — 2014-08-28T22:14:10+00:00

URL: https://externals.io/message/76924#76933 · In reply to: #76924

> 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

---

## #76934 — Andrey Andreev — 2014-08-28T22:34:47+00:00

URL: https://externals.io/message/76924#76934 · In reply to: #76933

Hi,

On Fri, Aug 29, 2014 at 1:14 AM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> 
> > […]
>
> 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

Tags preserve history well enough, as previously noted - they are
basically immutable branches. This looks like a no-brainer to me.

Cheers,
Andrey.

---

## #76935 — johannes@schlueters.de — 2014-08-28T22:44:42+00:00

URL: https://externals.io/message/76924#76935 · In reply to: #76934

> Tags preserve history well enough, as previously noted - they are
> basically immutable branches. This looks like a no-brainer to me.

This is not exactly true - we have cases where where, for whatever
reason, commits were made after the tag. i.e. I recently got the request
to add some CVE IDs to the NEWS file in 5.3 just for having them
documented in VCS.

I'd say it's trivial to create the historic repo and that will certainly
keep all history.

johannes

---

## #76936 — Andrea Faulds — 2014-08-28T23:12:35+00:00

URL: https://externals.io/message/76924#76936 · In reply to: #76935

> 
> 
> > […]
> 
> This is not exactly true - we have cases where where, for whatever
> reason, commits were made after the tag. i.e. I recently got the request
> to add some CVE IDs to the NEWS file in 5.3 just for having them
> documented in VCS.
> 
> I'd say it's trivial to create the historic repo and that will certainly
> keep all history.

I don’t see the need, though. For cases where we added stuff after release, just make an extra tag.
--
Andrea Faulds
http://ajf.me/

---

## #76937 — johannes@schlueters.de — 2014-08-29T00:03:18+00:00

URL: https://externals.io/message/76924#76937 · In reply to: #76936

> I don’t see the need, though. For cases where we added stuff after release, just make an extra tag.

$ git tag | wc -l
937
$ git branch -r | grep origin | wc -l
128

Not sure creating more tags makes things really "cleaner", I made a
proposal which can easily be implemented. If you don't like it, ok. If
you want to do more complex things: Fine with me.

Last message by me in this thread, there are way better things for
wasting time ... 

johannes

---

## #76941 — Andrey Andreev — 2014-08-29T06:54:30+00:00

URL: https://externals.io/message/76924#76941 · In reply to: #76937

On Fri, Aug 29, 2014 at 3:03 AM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> 
> > […]
>
> $ git tag | wc -l
> 937
> $ git branch -r | grep origin | wc -l
> 128
>
> Not sure creating more tags makes things really "cleaner", I made a
> proposal which can easily be implemented. If you don't like it, ok. If
> you want to do more complex things: Fine with me.
>
> Last message by me in this thread, there are way better things for
> wasting time ...

Indeed.

I guess a php-src-history.git is better than arguing whether to delete
something or not.

Cheers,
Andrey.

---

## #76947 — Derick Rethans — 2014-08-29T09:32:37+00:00

URL: https://externals.io/message/76924#76947 · In reply to: #76924

> 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

---

## #76949 — Julien Pauli — 2014-08-29T09:51:04+00:00

URL: https://externals.io/message/76924#76949 · In reply to: #76941

> On Fri, Aug 29, 2014 at 3:03 AM, Johannes Schlüter
> <johannes@schlueters.de> wrote:
> > […]
>
> Indeed.
>
> I guess a php-src-history.git is better than arguing whether to delete
> something or not.

I like the idea.
We should also update the docs (release-process?) if things are not
automated, or automate them if it is possible.

Julien.P

---

## #76950 — Pierre Joye — 2014-08-29T09:54:44+00:00

URL: https://externals.io/message/76924#76950 · In reply to: #76947

>
> 
>
> > […]
>
> 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.

I have no special opinions here but for the record you can always checkout
a tag.