Re: Crypt_RC4

On Wed, Jan 14, 2009 at 5:37 PM, Daniel O'Connor <daniel.oconnor@gmail.com>wrote: > Crypt_RC4 is unmaintained. > > Downloads stats say its fairly used ( > http://pear.php.net/package-stats.php?pid=50&cid=6) and > there are > dependencies by other packages on this. > > This makes me think: do a QA release, bump it to package.xml version 2.0, > etc. > > Unfortunately, the author went and did a BC break in CVS - > http://osdir.com/ml/php.pear.qa/2005-04/msg00042.html > > What's the best strategy here: > > Plan 1: > > - Create Crypt_RC42 (yeah, ick at name), and release that? > - Go back to the PHP4 branch, do a QA release with package 2.0 of that > (version 1.0.3) > - Have to investigate to see if bugs still exist that were fixed in > the other version, and fix them (probably do a 1.0.4 too that means) > > Plan 2: > > - Go back and remove all PHP 5 specifics (undo the PHP5 related BC break) > - Ensure the Crypt_RC4 API is backwards compatible > - Push out a 1.0.3 release, drop PHP5 compatibility > > > or something else? > I'd suggest Plan 3: - create a branch off the previous release's tag - roll a package2.xml release on it, since the only goal is to add package2.xml - merge the package2.xml change into the mainline (so that new release's info is intact in its package.xml files) - mainline now has a "history" of that release, while continuing to have the BC-moving-forward code on it I had to do this once with PhpDocumentor, once I'd gotten a handful of changes committed that had included a couple of enhancements. I created a branch in order to do a bugfix-only release, on which I merged all my previous non-enhancement commits. I did the bugfix release from this branch, merged only the package.xml changes into the mainline, and then was in perfect shape to do the feature release from the mainline. I believe I'm working with Till right now to accomplish this same path with a couple of other packages. -- CRB