Re: Re: Version naming

I did test this over 6 months ago - the mail is on the pear-core archives modifying the packager to create {package}-{version}-{state}.tgz was a few lines of code. in PEAR/Packager.php - function package() // {{{ TAR the Package -------------------------------------------

       $ext = $compress ? '.tgz' : '.tar';
       $dest_package = getcwd() . DIRECTORY_SEPARATOR . $pkgver . $ext;

// {{{ TAR the Package -------------------------------------------

       $ext = $compress ? '.tgz' : '.tar';
       $dest_package = getcwd() . DIRECTORY_SEPARATOR . $pkgver . '-' . $pkginfo['release_state'] . $ext;

the pear web site, however renames the file when you upload it.. (I dont dont see this as a problem, who cares how the pearweb stores the filenames internally.) - the only place I can see it being benifitial to use the long name is when you manually download the file to install it.. (without using the pear packager) I'm not sure how much is involved - but I would assume it probably just a matter of adding a Content-type: filename=..... to the dowload page. (and re-appending the same info there..) From what I remember, there is almost no place in pear that should depend on the filename.. - the package xml is used in all places??. (although package spoofing comes to mind a bit..) Is it really that complex? - it's a while since I dug that deep into the packager. Regards Alan Greg Beaver wrote:

anatoly techtonik wrote:

Only Package-version-state.tgz and Package-version.tgz

Still not going to do this. Package-state is allowed. You can't just make suggestions without taking a *complete* look at the way things work now. Anything else is a waste of both of our time.

If you want I can write these tests for you. Just tell where from to start. GB> and would have to not allow GB> Package-version-version GB> Package-state-state GB> The server side would also become much more complicated, and since the GB> question of "how stable is this package" can be answered by the use of GB> pear info and pear remote-info, I see no benefit in adding this extra work. But what about hostings with PEAR installed? I doubt they will allow executing "pear info" script. My shell session to upgrade scripts on such server will be something like uploading package, then tar -xzvf package.tgz So if I want to upload only stable version - I will have to choose packages without any prefixes. It is much better than checking all available files from machine, which have PHP+PEAR installed.

PEAR 1.4.0 allows easy synchronization of a remote host with a local copy. No shell scripts needed.

GB> I haven't even started to tackle the web frontend - considering how long GB> this will take, any features that are even slightly complicated will GB> have to wait.

I reiterate my first point - please do not make suggestions that clearly show you haven't done more than 10% of the research that needs to be done to understand how things work. Greg