Re: PEAR package retention policy

Hi Alexey, Looks great. I only have one minor addendum: Alexey Borzov wrote: > Hi, > > As suggested by Greg in "Importing packages into CVS" thread, I'm > posting a list of changes that should be done to PEAR guidelines and > pearweb. > > == Problem == > > Currently PEAR website allows package maintainers to delete packages and > package releases without any limitations whatsoever. This means that a > maintainer (or someone having his password) may delete a > several-years-old package with dozens of releases or delete any release > of said package. > > Such actions will affect all packages or applications depending on the > deleted package or requiring a specific deleted release of the package. > > == Proposed solution == > > In a nutshell, the proposed policy can be described as "Whatever was > released though pear.php.net, stays released". > > The ability to delete a package release shall be limited to releases not > older than two weeks (*). Package maintainers are advised to use this after "two weeks" add ", although in special circumstances, PEAR website administrators may remove a package release after this time, but only after a public posting on the pear-webmaster list with at least 1 week for discussion." > feature in the following cases only: > - Broken package definition file > - Missing required dependencies > - Wrong dependencies > - Missing files > - etc. > - Newly introduced severe bugs in stable releases (**) > - Severe violations of PEAR's coding standards and regulations > - Incorrect names in public API > - Incorrect package version > > The ability to delete a package shall be limited to packages with no > releases. > > = On "moved" packages = > > As some developers may wish to move their development away from PEAR's > infrastructure, there should be a means to announce this move (as > opposed to declaring their packages unsupported), closing the > bug-tracker and giving a prominent link to a new location. > > > (*) The actual period is discussable. > (**) Releases of stability level lower than "stable" are done for > testing purposes and are expected to contain bugs.