Re: PEAR 1.10
| From: | Alexey Borzov | Date: | Tue, 20 May 2014 22:18:28 +0000 |
| Subject: | Re: PEAR 1.10 | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-55338@lists.php.net to get a copy of this message | ||
Hi Christian,
Sorry for lack of movement on my part, I hope I'll be able to work on pear-core in a couple weeks' time
On 20.05.2014 0:58, Christian Weiske wrote:
I've re-migrated pear-core from SVN to git, preserving all the tags this time and using correct authorship information.All the commits on master branch show up as done by you now. :] https://github.com/pear/pear-core/commits/master
So we've got a 1.9 branch now that the last 1.9.5 release was based off, and master that contains all commits to date.There is a small problem with 1.9 branch... If I look at its commit history at github, it only shows 23 commits https://github.com/pear/pear-core/commits/1.9 And the first of these (click at your own risk) shows all the files in release 1.9.1 as added. And later ones do not look like merges either.
Unfortunately, version 1.9.2 was already off master by some dozen commits. Fixes were ported from and to master in the subsequent 1.9.x releases, but they were never in sync.I don't quite understand: were the 1.9.* PEAR releases done from SVN source or from Git? I don't see any 1.9 branch in SVN: http://svn.php.net/viewvc/pear/pear-core/branches/?pathrev=319707 Where did it come from? Also I noticed a very unorthodox approach to tags on Helgi's part: he e.g. created pear-core/tags/PEAR-1.9.4 from pear-core/tags/PEAR-1.9.3 and then merged stuff from trunk to the tag (!): http://svn.php.net/viewvc/pear/pear-core/tags/PEAR-1.9.4/?view=log&pathrev=319707 This works with SVN where branches and tags are the same thing, but I don't think this will export cleanly to Git...
What we can do now: - Port important fixes into the 1.9 branch, knowing that it's stable because the code lasted the last 4 yearsWe should probably discard the 1.9 branch, it is too broken. :[
- Stabilize current master with all the new features in it, making it ready as 1.10 releaseToo many new features, some of them not supported by unit tests...
- Find a point in time master was stable enough before all the github merges came in, make it the 1.10 branch and cherry-pick stable fixes into it.Looks like PEAR-1.9.1 was the last tag done from trunk without any funny stuff afterwards. I'd suggest re-branching from that point on master (this time with tests) and re-merging stuff added in subsequent releases.