Re: Re: [PEPr] +1 for RFC::VersionNaming

Greg Beaver wrote:

Alan Knowles wrote:

So i''m lost right now: take an example HTML_CSS package I've attempted to publish a new version in beta stage with a new feature inside. So how should it be named following this RFC ? ( previous version was 0.3.4 ) html_css-0.4.0.tgz

That should have been ok (the hope is that we can modify the packager/installer to create filenames like HTML_CSS-0.4.0-beta.tgz) based on the 0.4.0 release name.

This could throw a wrench into the idea of creating an xml-rpc-less channel server, as the user would need to know both the version and the stability. I think adding a postfix with state is going to be a bad idea whether it is automatic or not. 1) it does not distinguish between unique releases (HTML_CSS-0.4.0-beta.tgz and HTML_CSS-0.4.0-alpha.tgz is impossible) 2) it introduces another possibility for bugs and so adds a great deal of unneeded complexity to the script logic (pear install blah would have to check for such blunders as HTML_CSS-alpha-0.4.0 or HTML_CSS-alpha0.4.0)

From what I remember the filename is actually pretty irellivant to the packager - I've uploaded *-beta.tgz files to the pear web site, where it just strips the name and renames them at the other end. (I thought the non-xmlrpc version might just get pointed at a directory, with subdirectories and serve up what was in them, perhaps caching the package parsing?) It may not be worth targeting the first release as the test bed for this, but in the long term, we should be using the computer to make our life easier, (and it's life harder ;) Regards Alan

Greg