Release public beta test

[levi]

Just found this today - looks awesome!


Minor comments: it probably shouldn't offer to let you rate items until you've logged in. It does stop you if you try to rate it as is though.


I'm also not a big fan of the tag cloud style categories, but that's just my opinion and it's not a big deal - finding apps is nice and easy in this repo.


Below pages which just have a few comments, it says 'Back Next 1' - I'm assuming these are means to become links when there is more than one page, but it's a little cryptic as is.


Would it be possible to have one of the screenshots appear in the currently blank area below the description in the main info box? Either that or move preview pics above additional info, where both exist.


Using 'twiddly' arrows to indicate that 'Package Contents' can be expanded and collapsed would make it clearer to me what would happen before I clicked it.


Thanks for putting this together. I don't mean to be critical with my comments - it's great to use as is, and I haven't even tried the fancy developer back end.

 

[milkshake]

thanks for the comments ill take them into consideration (ill probably add the little arrows as you suggest).


UPDATE: users can now delete their own comments.

 

[gruso]

Your thoughts on this, milkshake?

Also note .. onyl dl.openhandhelds supports themes, pdfs, zips, etc; it must survive.


jeff

Is this something you might consider allowing in the future?

 

[milkshake]

Is this something you might consider allowing in the future?

I will definitely consider this in the future, there should probably be a separate spec if this is to be included in a native app.

 

[milkshake]

UPDATE:


OK I had a few people request this so......


I have added an option to stay logged in if you tick the box for this when you log in, every time you visit the site you will auto login (seamlessly without you knowing).


of course this is cookie based so if you don't enable them it doesn't work, also I have set an expiry date on the cookie to 30 days but that's plenty right?


I hope this really does encourage comments and app ratings.

 

[EvilDragon]

Would it be possible including older versions of apps as well?


Similar to how Filehippo.com are doing this

 

[milkshake]

Would it be possible including older versions of apps as well?


Similar to how Filehippo.com are doing this

this could be done... baring in mind its your bandwidth.. dunno how that would be implemented into the repo-spec but it could be implemented into the website somehow... although really as i was saying to someone else, if latest version isn't stable it shouldn't really be added as a release version and or the dev could have 2 versions on the site 1 beta version and one final version, this way the stable version always stays the same version until another stable release is ready but until it is users could download the beta version?

 

[EvilDragon]

Would it be possible including older versions of apps as well?


Similar to how Filehippo.com are doing this

this could be done... baring in mind its your bandwidth.. dunno how that would be implemented into the repo-spec but it could be implemented into the website somehow... although really as i was saying to someone else, if latest version isn't stable it shouldn't really be added as a release version and or the dev could have 2 versions on the site 1 beta version and one final version, this way the stable version always stays the same version until another stable release is ready but until it is users could download the beta version?

Even if it's stable, sometimes users want to downgrade again for whatever reason


And adding multiple versions of the same app to the store will just clutter the view.


No need to implement into the repo-spec. If a dev uploads a new version, the repo should just keep the old one as well and list it like filehippo.com does.


Of course the dev should be able to manually delete older versions, there might be reasons to do so (i.e. accidentally included non-free stuff that needed to be changed, etc.)


But Beta-Versions are a neat idea as well...


Maybe we could do it like this:


If a dev updates an app to a new stable version, it keeps the old version as mentioned above.


If the dev updates an app to a new beta version (maybe with a flag?), then the repo could show the beta versions the same way as the old versions.


Meaning:


If you select an app, it shows the latest stable version, and somewhere on the side it shows more recent beta versions as well as older versions of the app.


The user can then download these as well.


What do you think?

 

[PokeParadox]

Would it be possible including older versions of apps as well?


Similar to how Filehippo.com are doing this

this could be done... baring in mind its your bandwidth.. dunno how that would be implemented into the repo-spec but it could be implemented into the website somehow... although really as i was saying to someone else, if latest version isn't stable it shouldn't really be added as a release version and or the dev could have 2 versions on the site 1 beta version and one final version, this way the stable version always stays the same version until another stable release is ready but until it is users could download the beta version?

Even if it's stable, sometimes users want to downgrade again for whatever reason


And adding multiple versions of the same app to the store will just clutter the view.


No need to implement into the repo-spec. If a dev uploads a new version, the repo should just keep the old one as well and list it like filehippo.com does.


Of course the dev should be able to manually delete older versions, there might be reasons to do so (i.e. accidentally included non-free stuff that needed to be changed, etc.)


But Beta-Versions are a neat idea as well...


Maybe we could do it like this:


If a dev updates an app to a new stable version, it keeps the old version as mentioned above.


If the dev updates an app to a new beta version (maybe with a flag?), then the repo could show the beta versions the same way as the old versions.


Meaning:


If you select an app, it shows the latest stable version, and somewhere on the side it shows more recent beta versions as well as older versions of the app.


The user can then download these as well.


What do you think?

It could show alternate downloads in a drop-down, etc. I like this idea =)

 

[cosam]

No need to implement into the repo-spec. If a dev uploads a new version, the repo should just keep the old one as well and list it like filehippo.com does.

I'm not sure it can be done right without tweaking the spec. How does the repo know that this is a different version of the same package? And if the repo doesn't know, how can the package management client know? The way I interpret the spec is that package ID is unique between all packages, so unless you make assumptions about how the package ID is made up, there's no real link between different versions of the same package. This is kind of what I was getting at in my previous post. Updating a package did work for me though, so there is something magical happening.


Probably the easiest solution would to allow reuse of the same package ID, but to make the combination package ID and package version unique. You can then group all versions of the same package easily and reliably.

 

[milkshake]

it shouldn't be too difficult ill see what i can do got other stuff to do first though.

 

[EvilDragon]

I'm not sure it can be done right without tweaking the spec. How does the repo know that this is a different version of the same package? And if the repo doesn't know, how can the package management client know?

Well, there are version numbers in the PND, and each app has a unique ID.


So if you have a PND with "my_cool_app" as appid and "0.1.1" as version number and one with "0.1.2" as version number, it's pretty easy to find out

 

[cosam]

Well, there are version numbers in the PND, and each app has a unique ID.


So if you have a PND with "my_cool_app" as appid and "0.1.1" as version number and one with "0.1.2" as version number, it's pretty easy to find out

Yes, same principle - it's that simple ;-) We are however talking about packages as opposed to apps and if you take the spec as it's now written, there is no ID which remains consistent between versions at the package level, as package ID must be unique. You end up with IDs like "my_cool_app.whatever.011" and "my_cool_app.whatever.012" which you can't reliably match to each other as the contents are arbitrary.

 

[ivanovic]

No need to implement into the repo-spec. If a dev uploads a new version, the repo should just keep the old one as well and list it like filehippo.com does.

I'm not sure it can be done right without tweaking the spec. How does the repo know that this is a different version of the same package? And if the repo doesn't know, how can the package management client know? The way I interpret the spec is that package ID is unique between all packages, so unless you make assumptions about how the package ID is made up, there's no real link between different versions of the same package. This is kind of what I was getting at in my previous post. Updating a package did work for me though, so there is something magical happening.

WRONG! The package ID is meant to be the very same for packages that are just updates. Cf the documentation:

A good unique-id is the application name, developer name, and some key. The use of this ID is to allow repositories and package managers to differ between packages and recognize packages that require an update. So you should only update/change the ID of the package if you want an old one *not* replaced by the new/changed one.

http://pandorawiki.org/PXML_specification#The_.3Cpackage.3E_element

 

[cosam]

A good unique-id is the application name, developer name, and some key. The use of this ID is to allow repositories and package managers to differ between packages and recognize packages that require an update. So you should only update/change the ID of the package if you want an old one *not* replaced by the new/changed one.

http://pandorawiki.org/PXML_specification#The_.3Cpackage.3E_element

That certainly makes much more sense, but conflicts with the preceding paragraph which states that a package ID "should be something globally unique so that no two PND packages have the same id" and that "If this id already is used in another PND file, those two PND files will conflict with each other, and unforeseeable errors will occur". So I think you can understand the confusion ;-)

 

[milkshake]

That certainly makes much more sense, but conflicts with the preceding paragraph which states that a package ID "should be something globally unique so that no two PND packages have the same id" and that "If this id already is used in another PND file, those two PND files will conflict with each other, and unforeseeable errors will occur". So I think you can understand the confusion ;-)

yes the package id should be unique (unless your just updating your package/app).


my site assigns the up-loader as the owner of that package id so if someone else comes along by accident and tries to add a pnd with the same package id, unless they have been specifically added to the maintainers list for that pnd then they will not be able to overwrite it.


so it there should be no unforeseeable errors


at least not on my site, if there are multiple repo's its up to the package manager to decide which app with that specific id is delivered to the end user.

 

[milkshake]

Well, there are version numbers in the PND, and each app has a unique ID.


So if you have a PND with "my_cool_app" as appid and "0.1.1" as version number and one with "0.1.2" as version number, it's pretty easy to find out

this is true however my site uses the mantra "trust the dev" which means the owner/maintainer could update the app whenever he wants and decide not to update the version number at all or even upload an older version.


how would I be able to determine if the old pnd isn't just a buggier version of the new one if the owner did not update the version number?


hmmmm difficult one.

 

[EvilDragon]

how would I be able to determine if the old pnd isn't just a buggier version of the new one if the owner did not update the version number?

That's not your fault. If the author doesn't update the version number, the repo could warn him that it's the same version number and ask if he really wants to overwrite the current file.


Sometimes a dev has a typo in the PND or forgot to package one file, therefore, it's not really an update and the current non-working version should be overwritten.


But if there's really an update and the dev forgot to update the version number, it should warn him.

 

[milkshake]

That's not your fault. If the author doesn't update the version number, the repo could warn him that it's the same version number and ask if he really wants to overwrite the current file.


Sometimes a dev has a typo in the PND or forgot to package one file, therefore, it's not really an update and the current non-working version should be overwritten.


But if there's really an update and the dev forgot to update the version number, it should warn him.

Or i could just not add to list of old versions if the version number is the same and only then add to the list if a new version gets uploaded

 

[cosam]

yes the package id should be unique (unless your just updating your package/app).

Yep, all clear now. I did not however get that from the specification, so I've rewritten that part on the wiki. Someone may want to double check if it's accurate.