Waynn Lue wrote: > Yeah, that's why I was hoping to maintain a separate install, since it > would be easier to diff the patches. > > Shawn: Thanks for the suggestion to extend, I only wanted to make > small changes to an existing function though, so it's harder to do it > that way. My other thought was to refactor the underlying code base to > make it easier. > > Waynn > > On 7/5/09, Greg Beaver <greg@xxxxxxxxxxxxxxxxx> wrote: >> Waynn Lue wrote: >>> I wanted to makes some local edits to a PEAR package that I downloaded in >>> order to build some custom functionality into it. What's the best way to >>> manage this process to ensure that I don't accidentally blow away any >>> changes if I update the package? Should I just copy the entire package to >>> my own source repository, then use that directly instead of the PEAR >>> package? And if I do it that way, is there an easy path to upgrade it? >> Best would be to follow Shawn's suggestion. If you do need to make >> changes, you should contribute them back to the package, PEAR is an open >> public repository, it may be incorporated and help others in your >> situation as well (this is the point of PEAR and of open source). >> >> Greg >> Well, it depends upon the nature of your changes. You can copy the parent class's code and modify it in your class, or you can call parent::somefunc(); in your class and then run your custom code. It just depends upon what you are changing and how. I for one would never have anything in production (or was considered completed) where I had to diff files or look through code before I updated a package or framework. Actually, for me anyway, I wouldn't update/upgrade any shared library/component on a site/app unless I was still developing the code and it provided some extra functionality that I needed, or it patched a security vulnerability or maybe fixed a bad bug that I was struggling with. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
