Re: Crypt_HMAC vs Crypt_HMAC2

On Wed, Jan 14, 2009 at 11:14 PM, David Jean Louis <izimobil@gmail.com> wrote: > Bill Shupp a écrit : >> >> On Jan 14, 2009, at 12:12 PM, Christian Schmidt wrote: >> >>> Daniel O'Connor wrote: >>>> >>>> I'm guessing Crypt_HMAC is superceeded by Crypt_HMAC2; any objections to >>>> me >>>> marking the package as such? >>> >>> Crypt_HMAC2 is still in beta, though I assume it is reasonable mature and >>> ready for its 1.0 release (there hasn't been any CVS checkins for the past >>> 15 months, and there are no critical bugs). >>> >>> I suggest that Crypt_HMAC isn't marked as superceeded until Crypt_HMAC2 >>> is marked as stable. Otherwise the package is deprecated in favor of a >>> package that is (labeled as) poorer quality. >> >> This happens with other packages, like HTML_QuickForm and HTML_QuickForm2. >> I agree that marking a stable package as superseded by an unstable package >> is confusing. > > +1, packages should be marked as superseded *only* when a stable replacement > is available. > So what you guys suggest is that Crypt_HMAC2 is an example where the code has been around and proved to be is pretty solid -- otherwise larger issues would have manifested on the bug tracker. (So we all hope!) The issue I see is that if a package doesn't immediately superceed the other, people will not use it. So in turn, just because an alpha version has been around for X months and no bugs have been reported, doesn't really mean anything. It shows no evidence if the code is rock solid and ready for a stable release. To illustrate my thoughts: Crypt_HMAC2: http://pear.php.net/package-stats.php?pid=730&cid=6 Crypt_HMAC: http://pear.php.net/package-stats.php?pid=177&cid=6 I'm guessing not so many packages have added Crypt_HMAC2 as a depencency yet. LBNL -- we should not encourage developers/maintainers to race to 1.0 in order to create a stable release. If a premature 1.0 is released, it can backfire and makes things complicated. Don't know how to "implement" these thoughts or how to apply QA (e.g. require 100% test coverage, etc. (I remember seeing that somewhere with PEAR2)) to it, but I thought I'd mention it. ;-) Till