# Really going to 5.3.1RC1

- Thread: https://externals.io/message/45434
- Original archive: https://news-web.php.net/php.internals/45434
- Started by johannes@php.net on 2009-08-29T14:33:48+00:00
- Messages: 5
- 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

---

## #45434 — johannes@php.net — 2009-08-29T14:33:48+00:00

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

Hi,

I thought I sent the warning out on thursday but can't find it in my
internals folder therefore the notice:

  We certainly should get 5.3.1 rolling and therefore I'm planning RC1
  on Tuesday evening European time


I'm not toooo used to subversion therefore I'd like some comments about
this procedure:

1) Monday evening branch of a release branch owned by me
   $ svn cp branches/PHP_5_3 branches/php_5_3_1
   Question A: using php as in our tags or PHP as in our branches?
   Question B: can svn merge be used to get changes from PHP_5_3 or is a
               manual merge better?
2) Tuesday: Change the version
   $ vi branches/php_5_3_1/main/php_version.h etc.
3) making the branch a tag
   $ svn mv branches/php_5_3_1 tags/php_5_3_1
4) merge the tag into the PHP_5_3 branch
   $ cd branches/PHP_5_3 && svn merge ../tags/php_5_3_1
   The idea would be that the release appears in the
   branch's history and nothing is being lost
   Question: Does that make any sense?
5) Change the version to RC2-dev
   $ vi branches/PHP_5_3/main/php_version.h etc.


Feedback on this procedure and svn usage welcome. If this doesn't work
out the procedure can be changed for the next release and I guess a RC
is a better test than a "proper" release.

johannes

---

## #45438 — Jani Taskinen — 2009-08-31T08:23:34+00:00

URL: https://externals.io/message/45434#45438 · In reply to: #45434

> Hi,
>
> I thought I sent the warning out on thursday but can't find it in my
> internals folder therefore the notice:
>
>    We certainly should get 5.3.1 rolling and therefore I'm planning RC1
>    on Tuesday evening European time
>
>
> I'm not toooo used to subversion therefore I'd like some comments about
> this procedure:
>
> 1) Monday evening branch of a release branch owned by me
>     $ svn cp branches/PHP_5_3 branches/php_5_3_1
>     Question A: using php as in our tags or PHP as in our branches?
>     Question B: can svn merge be used to get changes from PHP_5_3 or is a
>                 manual merge better?
> 2) Tuesday: Change the version
>     $ vi branches/php_5_3_1/main/php_version.h etc.
> 3) making the branch a tag
>     $ svn mv branches/php_5_3_1 tags/php_5_3_1
> 4) merge the tag into the PHP_5_3 branch
>     $ cd branches/PHP_5_3&&  svn merge ../tags/php_5_3_1
>     The idea would be that the release appears in the
>     branch's history and nothing is being lost
>     Question: Does that make any sense?
> 5) Change the version to RC2-dev
>     $ vi branches/PHP_5_3/main/php_version.h etc.

I don't understand why you are merging things back and forth like that.
Just keep it simple:

PHP_5_3 is open for any commits, php_5_3_1 is only for commits you pick 
into it. And only do manual merge. Otherwise you won't be merging what 
you want for real. ;)

Don't mess with version in PHP_5_3, only in php_5_3_1 where you create 
the RCs from. And please, no more tags, those are totally useless in SVN 
world, IMO.

--Jani

---

## #45442 — Patrick ALLAERT — 2009-08-31T12:09:16+00:00

URL: https://externals.io/message/45434#45442 · In reply to: #45434

Hi Johannes,

2009/8/29 Johannes Schlüter <johannes@php.net>:

[snip]

> I'm not toooo used to subversion therefore I'd like some comments about
> this procedure:
>
> 1) Monday evening branch of a release branch owned by me
>   $ svn cp branches/PHP_5_3 branches/php_5_3_1
>   Question A: using php as in our tags or PHP as in our branches?

I would suggest keeping "PHP" for a branch because it will be used as
is, it can be renamed with "php" while doing the svn copy|move to
tags. More details after.

>   Question B: can svn merge be used to get changes from PHP_5_3 or is a
>               manual merge better?

The merge tracking is an interesting option, I would greatly recommend
using it. You can easily use the "-c" option to merge a specific
revision number.

> 2) Tuesday: Change the version
>   $ vi branches/php_5_3_1/main/php_version.h etc.
> 3) making the branch a tag
>   $ svn mv branches/php_5_3_1 tags/php_5_3_1

I would suggest a copy rather than a move because you may have to
create different tags (RC1, RC2,...) from this branch.

$ svn copy branches/PHP_5_3_1 tags/php_5_3_1RC1

> 4) merge the tag into the PHP_5_3 branch
>   $ cd branches/PHP_5_3 && svn merge ../tags/php_5_3_1
>   The idea would be that the release appears in the
>   branch's history and nothing is being lost

There is no such merge needed, svn keeps track of copies and merges.
From svn clients, it is perfectly possible to generate a graph with
copies (tags) made from that branch.

>   Question: Does that make any sense?

IMHO, No.

> 5) Change the version to RC2-dev
>   $ vi branches/PHP_5_3/main/php_version.h etc.

This should be made in branches/PHP_5_3_1, before the tag is created.

> Feedback on this procedure and svn usage welcome. If this doesn't work
> out the procedure can be changed for the next release and I guess a RC
> is a better test than a "proper" release.
>
> johannes

To summarize, I would recommend the following steps:

0° Creating the 5.3.1 branch

  $ svn cp branches/PHP_5_3 branches/PHP_5_3_1
  $ vi branches/PHP_5_3_1/main/php_version.h etc. // Filling next tag
information, e.g. 5.3.1RC1
  $ svn ci

1° Creating the 5.3.1RC(\d) tag

  $ svn copy branches/PHP_5_3_1 tags/php_5_3_1RC1

2° Lifetime of PHP_5_3_1:

  a) Patching PHP_5_3_1
  $ svn merge -c xxxxx branches/PHP_5_3 branches/PHP_5_3_1

  b) Fixing next version info
  $ vi branches/PHP_5_3_1/main/php_version.h etc. // Filling next tag
information, e.g. 5.3.1RC2, 5.3.1...

3° Goto 1° unless tagging the final release

4° Tagging final release:

  $ svn copy branches/PHP_5_3_1 tags/php_5_3_1

(optionally, branches/PHP_5_3_1 could be removed, but shouldn't be
"moved" as it would make a weird graph for merges/copies tracking)

Notes:
Developers commit should be made to branches/PHP_5_3 *only*
Release manager(s) only commit "svn merge" operations to branches/PHP_5_3_1
Tags are strictly read-only copies created with "php"
Branches are always created using "PHP"

Does this sounds good for you?

-- 
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor

---

## #45443 — johannes@schlueters.de — 2009-08-31T12:29:20+00:00

URL: https://externals.io/message/45434#45443 · In reply to: #45438

Hi,


> I don't understand why you are merging things back and forth like that.
> Just keep it simple:
> 
> PHP_5_3 is open for any commits, php_5_3_1 is only for commits you pick 
> into it. And only do manual merge. Otherwise you won't be merging what 
> you want for real. ;)
> 
> Don't mess with version in PHP_5_3, only in php_5_3_1 where you create 
> the RCs from. And please, no more tags, those are totally useless in SVN 
> world, IMO.

A "tag" makes sense to see what exactly was released and for that it
makes (in my opinion) sense if the svn mv/cp of the directory is the
last operation since that one can easily be identified. If we have no
separation between a branch and a tag this might be more problematic.

But I asked this on purpose, seeking advice, and don't have too strong
opinions there.

johannes

---

## #45445 — johannes@php.net — 2009-08-31T16:45:56+00:00

URL: https://externals.io/message/45434#45445 · In reply to: #45442

Hi,

thanks for your suggestions, some comments below:


> > […]
> 
> I would suggest a copy rather than a move because you may have to
> create different tags (RC1, RC2,...) from this branch.

good point.

> $ svn copy branches/PHP_5_3_1 tags/php_5_3_1RC1
> 
> > […]
> 
> There is no such merge needed, svn keeps track of copies and merges.
> From svn clients, it is perfectly possible to generate a graph with
> copies (tags) made from that branch.

The point is: diffing against the tags/ directory gives a way longer
diff command than diffing against an older revision of the same file ...
while svn is missing the "knowledge" about branches/tags ... that's the
thing where I really like CVS more than svn: 
    cvs diff -r SOME_TAG file.c
with svn that's either typing the full URL or tons of "../". And the
idea now was to simplify such a diff.

johannes