Re: not-yet-draft RFC on the new versioning standards for PEAR2 (needs PEAR Group sponsor to be official)

On Sat, Jun 27, 2009 at 11:51 AM, Greg Beaver<greg@chiaraquartet.net> wrote: > I've summarized the changes that could happen at this RFC address.  Feel > free to pick it apart - this needs to be rock-solid and clear.  Once it > seems to have settled, I'll seek a PEAR Group sponsor so they can take > it up. > Here is the RFC incomplete draft: > > http://wiki.php.net/pear/rfc/pear2_versioning_standard_revision This is something that came to mind regarding stability attributes... forgive me if they're incomplete thoughts. What purpose do the api and version stability attributes serve under this versioning RFC? If we adopt warnings regarding api version changes, then there is less risk installing a "beta" package, as you'll be warned if the api changes when you attempt an upgrade. Somewhat related - requiring 1.0.0 = stable. Under this proposed versioning standard, the developer releases 0.2.0, everything went great and would like to go stable. The API does not change as everything is perfect, but the developer is required to change the API version to 1.0.0 when he goes stable. Will this NOT upgrade with the default paranoia level because it is x+1? I understand the purpose of allowing development and major changes prior to a 1.0.0 release, but, if the package developer follows the instructions regarding api changes — and the installer will warn the user when the api changes according to their paranoia settings — why require them to use specific x numbering when a release reaches stable? Alternatively, the package hasn't reached stable yet, but I wanna break BC for all my alpha/devel/beta releases because I've got a better api design idea. So I want to use x+1 so that people following the development don't upgrade and break their code. Can I not do this? -- Brett Bieber