OXP Distribution and Packaging information

[Gimi]

Hmm. Why does it not matter? If I see the release date, I can quickly compare with the OXP List. If I see the version number, I have to go to the OXP's particular wiki page or BB thread to find out what the current version is.
This might not matter for a single OXP, but if you quickly want to go through your list, I think that having to compare against only one page is more efficient.

What was it you had in mind when you said it doesn't matter?

Point taken Maik. I think we work a bit differently. My thought was that both will show a difference (a new version) when compared to a list of installed OXP's (Log file). I don't use the list for checking versions much, I mostly pick up information on new versions from the forum. I use the list as a convenient way of quickly getting to the OXP-page on the Wiki. Well, I don't have a strong preference for either.
(I would like the version number or the date as a part of the name though.)

[Svengali]

I would have thought that having the version number would be beneficial, in that it makes it easier to see when an oxp is out of date and a new version is available.

Personally I want version numbers in the name. Or better: I hate oxps without version numbers and add them manually when they are missing.

I fully agree.

Regarding the point of version numbers: Wouldn't it be even easier to see if an OXP is outdated if the release date was appended?

I don't think so.
- for humans it's harder to read a date (in whatever flavour it comes) than a version number
- a update-application would have to lookup these things in all cases and it doesn't matter if it's a date or a simple number then
- a version number reflects the used version number in the scripts much better
That's why I've suggested to use version numbers for the OXP-List at the time of its (re)creation.

Oh, and using the date wouldn't be enough. Date+timestamp would be the way then. I doubt that you would want to compare your Latest.log against such a horrible long string (e.g. OXPNAME2011-01-01-15-30-02.oxp) for all your OXPs .-)

And duplicated OXPs is up to the User. Basics of OS handling is absolutely not OXPers responsibility. Maybe this sounds harsh, but you can't avoid Users errors without using a fully automated process and no other possible way of using AddOns. But then we are talking about binaries and/or registering to the core game functionality via update-application which would be completely against Oolites character (in my eyes).

Edit: Oh! Nearly forgot to say - good idea maik with the page. If a 'general' scheme can be found it will help Users, OXPers and Oolites Developers.

[Thargoid]

One negative point about using dates is different countries/regions use different orderings. So for example 090111 would be 9th January 2011 in the UK, but would be 1st September in the USA and 11th January 2009 in Japan. So if that route was used, then again a standard formatting would be needed.

But that's arguably similar with version number formatting, albeit less severe.

[maik]

One negative point about using dates is different countries/regions use different orderings. So for example 090111 would be 9th January 2011 in the UK, but would be 1st September in the USA and 11th January 2009 in Japan. So if that route was used, then again a standard formatting would be needed.

But that's arguably similar with version number formatting, albeit less severe.

What I proposed on the wiki page is the yyyy-mm-dd scheme, which is not really ambiguous.

[Micha]

Couple of suggestions to add:

1. Case sensitivity - especially Windows-OXPers should ensure that filenames in plists match the actual names of the files in case, not just spelling. Otherwise their creations break on other systems.

2. I would very strongly suggest properly filled out info.plist and requires.plist to be in every OXP. While they are primarily of use on Mac, they could be useful to future tools as they ensure certain OXP metadata is in a standard form.

3. Avoid spaces in filenames as they are irritating for people who use the command line. Use underscores instead (ie, MyShinyNewOxp_v1.23)

[maik]

Thanks, Micha. I added them in a new  General section.

[Eric Walch]

I think we need a separate paragraph for os specific stuff. If you not explain first that there is a slight problem, than users will ignore the advise. And I don't know how available zippers are for the mac. Since os 6 we used to have stuff-It with a different compression than zip. In OSX 10.2 was this stuff-It package included in the default install. There it also included a 'drop-zip' program that I still use. In the current OS releases it is no longer part of a default install.But, because the zip function is now part of the OS, there is less motivation for third parties to also release a zip program.

Anyhow, I just looked at the zipper "Ez7z". That has a function to inspect a zip archive. And that function does show the files that are normally hidden to a mac user. That way a mac user knows what a windows or linux user will see. Even better, you can select these special folders/files and delete them from the archive with one button.
Also will you see the hidden files like ".DS_Store" and ".LSOverride". Because OSX is build on unix, every file starting with a period, is invisible by definition. I know they become visible in windows.

(Till now I never found a way to check those zips for the special folders other than move the file to my old os7 mac and use my old tools on it)

Edit: YemugZip seems also very easy in use to create zip files that exclude the specific mac files.

[maik]

Thanks, Eric. I just found ZipCleaner, which takes a zip file that was created using the OS' compression and cleans it afterwards. Sounds like a good alternative.

[Eric Walch]

Thanks, Eric. I just found ZipCleaner, which takes a zip file that was created using the OS' compression and cleans it afterwards. Sounds like a good alternative.

Yes, it seems the best alternative to me also. I just tested it. It specific removes the "__MACOSX" folder and the ".DS_Store" files. These are the most common. It misses the less common ".LSOverride". That file store -among others- info about the program that should open this file when you don't want the default for that type. e.g. I often use it to define the drawing program that should open a specific PNG file.
But on testing does YemuZip also include this file when creating a windows compatible zip file. And now I got curious. I normally use dropZip from the stuffIt package for my oxps. That zipper also includes the ".LSOverride" file.

So when none of the alternatives does it better than the ZipCleaner, it will be the easiest advise for mac to use its build-in zipper and than clean the zip file.
- Right-click on the folder to compress and select the compress option. (Or ctrl-click when having a one-button mouse like me)
- Drop the resulting zip on the ZipCleaner to remove all mac specific files.

[maik]

I added info on both YemuZip and ZipCleaner to the wiki page.

[Captain Patrick]

Not clear to me what needs to be in a new OXP's Info.plist (capitalized?).

The one for the Oolite v1.76 application itself defines 30 entries; most OXPs that have it at all, show four – for example:

{
CFBundleGetInfoString = "UPS-Courier version 1.7.7";
CFBundleName = "UPS-Courier";
CFBundleShortVersionString = "1.7.7";
NSHumanReadableCopyright = "Eric Walch";
}

Guidance?

[JensAyton]

Not clear to me what needs to be in a new OXP's Info.plist (capitalized?).

Nothing. OXPs don’t need an Info.plist.

[Captain Patrick]

Not clear to me what needs to be in a new OXP's Info.plist (capitalized?).

Nothing. OXPs don’t need an Info.plist.

But at this time http://wiki.alioth.net/index.php/OXP_Distribution says:
"Include info.plist and requires.plist in your OXP. "

Perhaps should delete here "info.plist and"? (or, even If not, probably still need to capitalize to Info.plist, as per its occurrence in Oolite.app/Contents/, and generally with the Mac).