looking for help on project

[milkshake]

For example, you'd need very specific information which may neither be in the PND nor in the site you plan to collect it from, like the version of the pnd, release notes, previous versions etc. Also, since the program might have been done by multiple people on different hosts, there may be different concurrent versions of an app if that side-load is activated. Question is, which one to select? let the user decide? how is the user supposed to know which of those versions is the most recent one?

each pnd contains the version number of the app, as long as the apps developer follows the PXML standard my site checks the app id which is unique to each app but not unique for each version, then it checks the version number so if the version the user is trying to add is older than the one on my server it will say so, if its newer it will update the old db entry.


if there are different versions from different developers then a different app id should be used as they are no longer the same app but offshoots of the original.


in which case it will add a new entry based on the apps id.


for those few developers that dont follow the PXML standards it will either add a new entry based on the app id they provided in the PXML or tell them there PXML data is not to spec.


easy

If it downloads from other PND sites without user interaction, you have other problems.

what other problems?


It can currently go through the official app-stores full collection just be me running a script and get each file, and check for duplicates/updates etc before proccessing each pnd. I have implamented lots of ways of checking for errors and duplicate apps(took me ages).

If it works with the official PND repos, you would probably be able to have it preinstalled on the Pandora as the official package manager.


Yet, when you just make your own repository that does not work with the official one.. well, there may be some people who would still use it, maybe even a whole bunch of people, but for me personally, it would be nothing.

Im following the repo and PXML specs from the pandora wiki so if they implamented the same spec eventually then a native app manager could have access to mutliple repos that are user added (the user doesnt need to add additional repos if they dont want to) so thats not really an issue.


The issue is the OPT have not implamented anything like this as of yet and I got tired of waiting.

I'd say get your DNS record fixed and post a demo (if you have a demo, that is) in a new thread in the general section and see what other people have to say.

am in the process of trying to get this fixed hold tight.

 

[Klaue]

each pnd contains the version number of the app, as long as the apps developer follows the PXML standard my site checks the app id which is unique to each app but not unique for each version, then it checks the version number so if the version the user is trying to add is older than the one on my server it will say so, if its newer it will update the old db entry.

App-version is not PND version.


Use-Case:


Oh hey, I prted pacman ultimate 4.21.3.2! let's make a pnd and upload it.


id = pacmanultimateohmygoditsawesome (or whatever), version = 4.21.3.2


Oh, I found a nifty way to increase the performance of pacman ultimate 4.21.3.2 on the pandora/I found a bug and corrected it, let's make a new pnd with that fix!


id = pacmanultimateohmygoditsevenawesomer (or whatever), version = 4.21.3.2


so.. if you have those id's and those version tags, both of which are correct, how do you determine the newer one without an additional pnd-version-tag?


you see the problem?


Either one would have to rewrite the spec to include a pnd-version-tag or everyone would have to re-brand their pnds (openoffice 3.6 -> pndOpenOffice 1.0) which would make things really ugly.


EDIT: Another possibility would be to handle this just on your server. Make user accounts and if the same user uploads the same app with the same version again, update an internal pnd-version entry in your DB. But that would mean that getting the PNDs from a third party source (like the official app db) wouldn't work anymore. (but there are allready other problems with that, for example the server load - to make sure you have all apps in the most recent version, you'd have to download every app off the official app store once a day)


the other stuff like release notes, which would be crucial for any updater, are also not in the pxml spec. for the purpose of an downloader/installer/updater, the pxml, in it's current form, isn't enough.

if there are different versions from different developers then a different app id should be used as they are no longer the same app but offshoots of the original.
in which case it will add a new entry based on the apps id.

that wouldn't help a potential user. all he would have is various pnds of the same app with the same version just by different people, without any way to fnd out which one is better - not even release notes which could state how complete the port is (IMHO, release notes != description).

what other problems?

For example all the ones listed in the previous part of the post?

Im following the repo and PXML specs from the pandora wiki so if they implamented the same spec eventually then a native app manager could have access to mutliple repos that are user added (the user doesnt need to add additional repos if they dont want to) so thats not really an issue.

The repo spec is, too, not mature, because it lacks, again, such stuff like the pnd version and the release notes. AFAIK there are currently no implementations of it, so changing it would be way easier than changing the pxml spec.


btw, most if not all of the above mentioned problems (which, as I'm pretty sure, will come back and bite you in the behind sooner or later) were allready discussed in the thread I linked you to at the start of this thread.

 

[sebt3]

App-version is not PND version.


Use-Case:


Oh hey, I prted pacman ultimate 4.21.3.2! let's make a pnd and upload it.


id = pacmanultimateohmygoditsawesome (or whatever), version = 4.21.3.2


Oh, I found a nifty way to increase the performance of pacman ultimate 4.21.3.2 on the pandora/I found a bug and corrected it, let's make a new pnd with that fix!


id = pacmanultimateohmygoditsevenawesomer (or whatever), version = 4.21.3.2


so.. if you have those id's and those version tags, both of which are correct, how do you determine the newer one without an additional pnd-version-tag?


you see the problem?

That's what the "build" tag is for...


EDIT: The release note should be part of the documentation.


Before setting comment like these, please, pretty please read the documentation rightfully and make sure you have get all (by using it...)

 

[milkshake]

App-version is not PND version.


Use-Case:


Oh hey, I prted pacman ultimate 4.21.3.2! let's make a pnd and upload it.


id = pacmanultimateohmygoditsawesome (or whatever), version = 4.21.3.2


Oh, I found a nifty way to increase the performance of pacman ultimate 4.21.3.2 on the pandora/I found a bug and corrected it, let's make a new pnd with that fix!


id = pacmanultimateohmygoditsevenawesomer (or whatever), version = 4.21.3.2


so.. if you have those id's and those version tags, both of which are correct, how do you determine the newer one without an additional pnd-version-tag?


you see the problem?

in this case because the id is different in each case then the updated app will be added to the database as its own unique application.


the whole point of the app id is so if an application gets a bug fix and updated the ap id is ment to stay the same in each pnd (old and new) but the versionnumber would change thats why the id was implmented (ap_id != app title).


at the end of the day I cant help it if OPT don't implament a better PXML spec and I cant help it if the person that may package up a pnd doesn't follow the existing spec correctly.


All I can do is work with what spec has been implemented; I can say I have done this has the official app store?


...Nope, so how would they cope in ur above scenario? they wouldnt there is nothing to check this.


As a backup My site could have a group of willing moderators who check each app thats uploaded before allowing it to added to the db (either new app or updated app), but I dont really want to go down that route. Even if I do go down that route at least lots of pre-checks will have been completed before hand making there job easier.

Either one would have to rewrite the spec to include a pnd-version-tag or everyone would have to re-brand their pnds (openoffice 3.6 -> pndOpenOffice 1.0) which would make things really ugly.

This really wouldnt need to be done as long as people stick to the spec.

the other stuff like release notes, which would be crucial for any updater, are also not in the pxml spec. for the purpose of an downloader/installer/updater, the pxml, in it's current form, isn't enough.


that wouldn't help a potential user. all he would have is various pnds of the same app with the same version just by different people, without any way to fnd out which one is better - not even release notes which could state how complete the port is (IMHO, release notes != description).

If adding release notes to the description is good enough for apple why is it not good enough for us?


Do you really think this is needed? if an update is added is it really that hard for the app developer to update the PXML description with any release notes?

For example all the ones listed in the previous part of the post?

I still done see ur point?

The repo spec is, too, not mature, because it lacks, again, such stuff like the pnd version and the release notes. AFAIK there are currently no implementations of it, so changing it would be way easier than changing the pxml spec.


btw, most if not all of the above mentioned problems (which, as I'm pretty sure, will come back and bite you in the behind sooner or later) were allready discussed in the thread I linked you to at the start of this thread.

(version == pnd version) there really is no difference, its the version of the app in its existing form i.e. major.minor.release.build the way we would see which pnd it belongs to would be the app_id.


if someone wants to release an updated version of an app they have 2 options - release it as an official update keeping the existing ID in tact or release a seperate version giving peope a choice in which case he would change the app_id slightly.


just out of curiosity have you read the PXML specs in detail? because I have many, many times.

 

[Klaue]

That's what the "build" tag is for...

The build tag is part of the version. It is usually updated by hotfixes. even the version tag reflects this


<version major="1" minor="1" release="1" build="2"/>


"The build attribute specifies what build the application is at. This number should be 0 or more."


"the application". Not "the PND"


Excerpt from wikipedia:


Other schemes impart meaning on individual sequences:


major.minor[.build[.revision]]


or


major.minor[.maintenance[.build]]


You see, build is a common part in software versioning. what gave you the idea it was the build of the pnd file?


For example, my currently installed Java is v. 1.6.0 build 23 (1.6.0_23), so the version tag would be


<version major="1" minor="6" release="0" build="23"/>


Where would you put the PND version then?


my company'sproduct is currently at version 5.1.6.100


<version major="5" minor="1" release="6" build="100"/>


still no place for PND version.


The release note in the documentation is also not enough. Ever used apt, or any other package manager for that matter? then you may understand why it's important to have the release notes readily aviable on the server.


Before posting a comment like this, please, pretty please read and understand the post you're referencing to and don't be so condescending, thank you very much.

the whole point of the app id is so if an application gets a bug fix and updated the ap id is ment to stay the same in each pnd (old and new) but the versionnumber would change thats why the id was implmented (ap_id != app title).

The speck in the wiki says that no two pnds should have the same ID, so reusing it would never be allowed, because a bugfix would be a new PND. But even if you'd use the id that way, the problem persists because even then, the verion of the app doesn't change. java 1.6.0_23 will stay java 1.6.0_23 even when you fixed an accidental write to the NAND..

at the end of the day I cant help it if OPT don't implament a better PXML spec and I cant help it if the person that may package up a pnd doesn't follow the existing spec correctly.

the thing is that one should try to at least get them to update the spec before beginning to implement it. If you allready have hundrets of progs in your repository, it's night-impossible to retroactively change that, so the sooner the spec gets updated, the better.

Do you really think this is needed? if an update is added is it really that hard for the app developer to update the PXML description with any release notes?

This is a bit more philosophical. A description and a release note (containing the change list) are, in my opinion, two sepparate things. One could put them together, but that wouldn't be a particularly beautiful solution

(version == pnd version) there really is no difference, its the version of the app in its existing form i.e. major.minor.release.build the way we would see which pnd it belongs to would be the app_id.

again, there is a difference. you make one pnd of java 1.6.0.23, then you fix a bug in it or anything WITHOUT THE JAVA VERSION CHANGING and you have, yet again, a pnd with the version tag 1.6.0.23 because the java-version just did not change. even with the same ID there's no way to tell which of the two is more recent besides maybe file date.


If you would just delete the old version and just say "this version currently on my server is the current one, even if I have no idea which version it actually is", then that would make debugging for the people who made the PNDs hell, because they wouldn't know which version the people are running. That may not seem like a big issue, but it's one of the main reasons there are such things like version numbers.


Seriously, am I writing chinese without noticing it? That would be funny, because I don't know any chinese. Still, I get the feeling nobody understands me.

 

[milkshake]

the version inside the PXML is the PND version not the software version or at least thats how it is meant to be used.

The speck in the wiki says that no two pnds should have the same ID, so reusing it would never be allowed

yes this is true but it relates to having 2 totally different apps with the same id would be wrong but it is meant to stay the same if its the same application - unless the person who wrote the specs can confirm I have got this incorrect.


I hope I havent said anything that would seem condescending.

 

[sebt3]

Before posting a comment like this, please, pretty please read and understand the post you're referencing to and don't be so condescending, thank you very much.

I didt meant to arm you. But you're criticize something that works without having a chance to use it.


My major work provider (Oracle) use 5 digits to mark it's version numbers so even 4 can be too small. But in the end of the day, they realy use only 3 (major, minor, patchset level) these days.


I've packaged a lots of stuff now, and I've yet to feel a problem with the version numbering. Some projects even only use 2 levels of numbers. So I have feed one with 0 myself.


The build number is deeply connected to the plateform as you might have guessed. The plateform is pandora ; we build our software ourself, so I cant see how the build number isnt to be used by the packager (aka the one that is actually building the software)...

 

[WizardStan]

the version inside the PXML is the PND version not the software version or at least thats how it is meant to be used.

The version tag is really however the person creating the PND wants it to be. The spec says "application version" but really the PND can be considered "the application". It makes it easier if the version tag being given bears some resemblance to the program being started in the PND, but it's not strictly necessary.

yes this is true but it relates to having 2 totally different apps with the same id would be wrong but it is meant to stay the same if its the same application - unless the person who wrote the specs can confirm I have got this incorrect.

The application ID is supposed to be unique between distinct applications, yes. A bug fix is still the same application. In fact, a more advanced version is supposed to have the same ID as an older version. Think of it like a package name. You do "opkg install java" and it gets the latest version of java. The package name doesn't change with a new version.

 

[milkshake]

The version tag is really however the person creating the PND wants it to be. The spec says "application version" but really the PND can be considered "the application". It makes it easier if the version tag being given bears some resemblance to the program being started in the PND, but it's not strictly necessary.

so basically say your updated your application your 'pnd' with a bugfix then technially you should really at least increate the build number... thats how i would interpritate it.

The application ID is supposed to be unique between distinct applications, yes. A bug fix is still the same application. In fact, a more advanced version is supposed to have the same ID as an older version. Think of it like a package name. You do "opkg install java" and it gets the latest version of java. The package name doesn't change with a new version.

excellent thats what I already thought the pnd wiki could do with being reworded infact your explanation was soo good maybe they could use your terminolgy

 

[milkshake]

ok moving on from the current discussion back to the progress of my site..


what I plan to implament in the next few days:

1. a page which generates the data in my database as JSON which should be easy really.
   
2. a html table generated with a list of apps, this will include the pnd icon, application title (the default en_US or en_GB one) and the version number.
   • Then when you click on an app it will display the full app info including description etc.
     

This will be basic stuff just to show people that it works then once I have all the basic stuff down I will make it more exciting i.e. app rating, report app options, ajaxify with jquery etc etc

 

[Klaue]

My major work provider (Oracle) use 5 digits to mark it's version numbers so even 4 can be too small. But in the end of the day, they realy use only 3 (major, minor, patchset level) these days.


I've packaged a lots of stuff now, and I've yet to feel a problem with the version numbering. Some projects even only use 2 levels of numbers. So I have feed one with 0 myself.


The build number is deeply connected to the plateform as you might have guessed. The plateform is pandora ; we build our software ourself, so I cant see how the build number isnt to be used by the packager (aka the one that is actually building the software)...

fair enough, but then the spec should clearly say that. Maybe if someone has an account in the wiki, he could go change that. Maybe it's just me being dumb, but, to take java as an example again, I would never have thought of setting the version to "1.6.0 build 1" (for the first PND). I wonder how many of the PNDs allready out there actually used it that way, or better, how many do not.


IF you would constantly use the build for the PND and not for the build number of the application encapsulated within, then it would work. The changelog would still be missing, but if that's the only thing, one could put it in the description. not really great, but good enough, I think.

The version tag is really however the person creating the PND wants it to be. The spec says "application version" but really the PND can be considered "the application". It makes it easier if the version tag being given bears some resemblance to the program being started in the PND, but it's not strictly necessary.

Shouldn't it be made neccessary? If such an updater/downloader/etc is ever going to work properly, there has to be some standard. For example, assume you have a program, minecraft or whatever, that has java 1.6 as a dependency. you search for a java package and all you find is one with version "1.0.0.0" because it's the first PND - that would be of no help at all. Using the build number for the PND version is OK, as long as the spec makes that clear, but saying that the whole version tag could just be the version of the PND and not of the encapsulated program doesn't make much sense to me.

The application ID is supposed to be unique between distinct applications, yes. A bug fix is still the same application. In fact, a more advanced version is supposed to have the same ID as an older version. Think of it like a package name. You do "opkg install java" and it gets the latest version of java. The package name doesn't change with a new version.

How about changing the description from "The "id" attribute specifies an identifier for your PND package, and should be something globally unique so that no two PND packages have the same id." to something like "The "id" attribute specifies an identifier for your PND package, and should be something globally unique so that no two applications of divverent versions have the same id"


I don't want to be anal, but I think a spec should be as precise as possible and leave no room for interpretation.

 

[milkshake]

I agree the wording on the spec description needs to be improved


I understand the issue you are saying with the java example but say you search for a java on my site it should return any apps with java in the title so if there is more than one version the version should be stated in the description, i know its not ideal but the way the specs are at the moment it would work.

 

[Klaue]

i know its not ideal but the way the specs are at the moment it would work.

That's why I would rather change the specs to make it ideal


Btw, dns error persists

 

[milkshake]

ok 1 tick off my list I posted earlier.


my JSON repo list is here.


this is follows the current repo-spec perfectly


so tempel if you wanna test the output with what you have done so far to check it works?


also when it comes to downloading the app the way I will do it is to force download using headers to change the name so that file the browser recieves is different to the pnd stored on the server.


although I haven't implemented this yet

$file = "./directory/sd76fd766fd.pnd":


// It will be called name according to id and version number

$appName = $data['id'].$data['version'].".pnd";


if(file(exists($file)){

    header('Content-Description: File Transfer');

    header('Content-type: text/plain');

    header('Content-Disposition: attachment; filename="$appName"');

    header('Content-Transfer-Encoding: binary');

    header('Cache-Control: must-revalidate, post-check=0, pre-check=0')

    header('Content-Length: ' . filesize($file));

    ob_clean();

    flush();

    readfile($file);

    exit();

}

well it turns out my domain name expired I though it had another year, so I renewed it and it should flood back through all the DNS servers shortly, on my computer it now works at least .


if you want to test the sideload/upload form Klaue its here


ok so now I have my JSON yay.


edit:


I will have separate arrays if you want me to provide any app ratings? or subcategories? or comments etc. etc.

 

[milkshake]

UPDATE:


we have a basic table with the apps from my site - not the final design this is just a test.


view here

 

[Tempel]

I've only skimmed all the arguments and counterarguments, but I have a thought on the version-numbering issue:


Couldn't we use a single version field containing a string? As Klaue points out, having only four digits available can be constraining, especially if the app being packaged already uses that many or more. But more important to me is the fact that only integers are allowed, not strings; I can't release version 1.1beta3, I can only release 1.1.3, which makes this beta release indistinguishable from a final release. I know this makes sorting packages by version (and determining which is newer) a little more difficult, but it's standard behaviour in all Linux package managers I've tried.


So yeah, that's my proposed solution here, though I suppose it's moot if making the transition is difficult.

 

[Klaue]

@milkshake:


Your JSON is faulty. Or better, not the JSON as is is faulty, but the data in it: you escaped every forward slash, while all you have to escape in JSON are single quotes, double quotes, backslashes and control characters.


Did you do it yourself? The easiest way would be to just put your data in arrays of arrays and then call json_encode(), like:

$repos = array();

$repos["repository"] = array();

$repos["repository"]["name"] = "milkshakes-repo";

$repos["repository"]["version"] = 1;

$repos["applications"] = array();

$repos["applications"][0] = array();

$repos["applications"][0]["id"] = "uae4all";

[...]

echo json_encode($repos);

Note: I did not test it - could be that it does actually look different from the repos that way, in that case, I'd try the JSON_FORCE_OBJECT parameter and if that still doesn't work, then you probably have to do it yourself.


Also, you seem to have mixed up the non-english descriptions, example of a particularly weird one:


"en_US":{"title":"Minitube","description":"Watch YouTube videos"},


"de_DE":{"title":"Comix","description":"der Comix"},


"nl_NL":{"title":"PandoraPanic!","description":" PandoraPanic! Een panische minigame collectie voor de pandora door leden van het GP32X Forum"},


"en":{"title":"Pandora Fractals Drawer","description":"A homebrew Mandelbrot Set drawing application with zooming capabilities as well as screen shot saving."},


"de":{"title":"Pandora Fractale Schublade","description":"Ein Homebrew Mandelbrot Set Zeichenprogramm mit Zoomfunktionen sowie Screenshot speichern."}


Probably this is just a JSON-building-error, let's hope it's not that way in your DB


EDIT: By the way, whoever machine translated fractal drawer to fractale schublade, thanks for the laugh (Schublade = drawer like the ones in a cabinet)

But more important to me is the fact that only integers are allowed, not strings; I can't release version 1.1beta3, I can only release 1.1.3, which makes this beta release indistinguishable from a final release.

Not only that, but some apps use non-numerical version "numbers" even outside of just "beta". For example, WordPerfect has versions X3 and X4 instead of 13 and 14, photoshop uses stuff like "CS2", Windows uses "XP", "ME" etc, other software uses the release date, yet other ones use numbers, but with an additional version name (many linux distributions do this, ubuntu for example) and so on. (Note: those are only examples, I do not expect anyone packaging windows xp for the pandora )


a version tag like


<version application="1.5.3928192.3 beta 2" pnd="1">


could handle all that, but oh well.

 

[milkshake]

@tempel


Hey I read ur post on gp32x but i cant access that page from work so I cant reply there.


I had a think about what you said and if we use a datetimestamp send in your json request url i.e. op.liquidfists.com/includes/getData.php?&dt=thedatethetime


it is possible for my server to see if we have updated it since that date/time then send the load the info out.


but the problem is timezones I hate them, maybe we can use the universal unix time or is it UTC time in seconds since January 1, 1972 onwards, so no matter which part of the globe my server gets a request from we should be able to compare unix time?


I know its not official but I think we should deffinatley include screenshots in a possible future spec, and I agree with the comments idea include a URL to JSON formatted comments in the spec maybe like u suggested?


yeah again ratings counld be sent in % or maybe as float? e.g 4.5 (this would be out of 5 of course but u only send the value that it is currently rated?).


lets keep this going Its good to think about stuff


edit:


been thinking even more about it and if you wanted to collect all the json you could just call the page directly without any aditional elements i.e.


op.liquidfists.com/includes/getData.php


when you receive the json you could log the UTC datetime locally then the next time you visit you could call.


op.liquidfists.com/includes/getData.php?&dt=UTCdatetimestampand


my site would then only send any additional or updated entries via JSON?


this sounds like the best way what do you think?

 

[milkshake]

@milkshake:


Your JSON is faulty. Or better, not the JSON as is is faulty, but the data in it: you escaped every forward slash, while all you have to escape in JSON are single quotes, double quotes, backslashes and control characters.

when the data is in the array there is no escape, only when I call json_encode() do the escaped characters appear, i belive this is how its meant to be, plus using double quotes when reading back the string would process the backslashs and not display them anyway only single quotes would keep them there.

Did you do it yourself? The easiest way would be to just put your data in arrays of arrays and then call json_encode(), like:

$repos = array();

$repos["repository"] = array();

$repos["repository"]["name"] = "milkshakes-repo";

$repos["repository"]["version"] = 1;

$repos["applications"] = array();

$repos["applications"][0] = array();

$repos["applications"][0]["id"] = "uae4all";

[...]

echo json_encode($repos);

Note: I did not test it - could be that it does actually look different from the repos that way, in that case, I'd try the JSON_FORCE_OBJECT parameter and if that still doesn't work, then you probably have to do it yourself.

i pretty much coded it exactly like that, lol i did not manually create the json i did use json_encode().

Also, you seem to have mixed up the non-english descriptions, example of a particularly weird one:


"en_US":{"title":"Minitube","description":"Watch YouTube videos"},


"de_DE":{"title":"Comix","description":"der Comix"},


"nl_NL":{"title":"PandoraPanic!","description":" PandoraPanic! Een panische minigame collectie voor de pandora door leden van het GP32X Forum"},


"en":{"title":"Pandora Fractals Drawer","description":"A homebrew Mandelbrot Set drawing application with zooming capabilities as well as screen shot saving."},


"de":{"title":"Pandora Fractale Schublade","description":"Ein Homebrew Mandelbrot Set Zeichenprogramm mit Zoomfunktionen sowie Screenshot speichern."}


Probably this is just a JSON-building-error, let's hope it's not that way in your DB


EDIT: By the way, whoever machine translated fractal drawer to fractale schublade, thanks for the laugh (Schublade = drawer like the ones in a cabinet)

i have not noticed this, when i get home ill check it out.

Not only that, but some apps use non-numerical version "numbers" even outside of just "beta". For example, WordPerfect has versions X3 and X4 instead of 13 and 14, photoshop uses stuff like "CS2", Windows uses "XP", "ME" etc, other software uses the release date, yet other ones use numbers, but with an additional version name (many linux distributions do this, ubuntu for example) and so on. (Note: those are only examples, I do not expect anyone packaging windows xp for the pandora )


a version tag like


<version application="1.5.3928192.3 beta 2" pnd="1">


could handle all that, but oh well.

we can have a seperate entry to declaire the software alpha, beta or final that could help in the meantime no?

 

[foxblock]

But more important to me is the fact that only integers are allowed, not strings; I can't release version 1.1beta3, I can only release 1.1.3, which makes this beta release indistinguishable from a final release.

Not only that, but some apps use non-numerical version "numbers" even outside of just "beta". For example, WordPerfect has versions X3 and X4 instead of 13 and 14, photoshop uses stuff like "CS2", Windows uses "XP", "ME" etc, other software uses the release date, yet other ones use numbers, but with an additional version name (many linux distributions do this, ubuntu for example) and so on. (Note: those are only examples, I do not expect anyone packaging windows xp for the pandora )


a version tag like


<version application="1.5.3928192.3 beta 2" pnd="1">


could handle all that, but oh well.

But, as Tempel points out in the rest of his quote, this makes comparison between version numbers near impossible (and this is the best way to determine whether an app has been updated, you can't really rely on the upload date).


Also all examples you mentioned are just the string variant of the version number, there always is an integer based version - Photoshop CS for example translates to 10.x , Windows XP to 5.1, etc. These numbers are also used internally. The sting variant is just a fancy way of displaying it as "XP" sounds cooler than "5.1" and makes the difference more clear.


Therefore the best way imo to solve this is to add some kind of flags to the version tag like (with pre-defined values).

<version major='number' minor='number' release=number build='number' flags='beta,alpha,pre-release,gold,whatever' />

Those flags could be used to distinguish between different types of releases with a consistent version number (so they don't get checked for comparison, but rather show up as a label).


Apart from that I don't really see the problem, I doubt anyone has to use more than 4 sections for a version number (btw, 4 sections != 4 digits, you can use full integer numbers for each of the fields), adding the (optional) flags should be more than enough.


Even without the flags one could branch beta releases in a different pnd and use the build-part of the version number to distinguish between final releases.


Anyway, this should be moved to another topic imo...


On-topic: Looking forward to the site and program, a software based browser for downloading PNDs is one of the things making the Pandora feel more "professional".


foxblock out