Updating the module page

Hi,
I’ve updated the Export module to allow use with Omeka S 2. For some reason, the update hasn’t been pushed to https://omeka.org/s/modules/ from the Github release (https://github.com/lauraleif/Export).

Are there additional steps and/or criteria I should complete to get the update pushed to the page.

Thanks,
Laura

It looks like all your releases beyond the first one are missing the necessary top-level “Export” folder in the zip upload.

Thanks for letting me know (sorry I missed this message initially). I created a new release with a top-level Export folder in the zip upload 3 days ago and am checking daily to see if the newer version is pushed to the release page. If it isn’t automatically picked up, is there a point at which I should look into troubleshooting again? For example, if the releases are pulled daily, I should investigate now, but if they are weekly then I probably just need to wait.

I took a look at your new .zip: it has two levels of “Export” folders, not just one, so that wouldn’t be accepted either. So inside your zip you have the file Export/Export/Module.php, when it’s meant to be Export/Module.php.

You can have Git create the zip for you with the correct structure, which is what we suggest in the documentation page about releasing modules:

git archive --output=Export-1.4.1.zip --prefix=Export/ Exportv1.4.1

That command, run from within your local Export repository, will produce a zip named Export-1.4.1.zip with the correct single “Export” folder at the top level, using your “Exportv1.4.1” tag. The tag name “Exportv1.4.1” that you’ve used here is a little odd; conventionally it would just be “v1.4.1” but it should work fine anyway.

In terms of how long things take to update: the registry updates itself every day.

I should also add: you should be able to simply remove the problematic zip file and upload a new one to the release: you don’t need to make a new tag for that purpose.

A final question: I see your last handful of updates explicitly eliminates support for the current 2.1 release series? Was there some issue there?

That’s helpful, I wasn’t sure what would trigger the process. I don’t know of any compatibility issues with the 2.1 release, but haven’t explicitly tested for compatibility either. The last significant code changes to the module predated the current Omeka S release.

OK.

The reason I ask about the compatibility is that the way it’s written now with the < 2.1 in there just prevents people from running the module on Omeka S 2.1 at all (this happened in the other thread about this module).

In general, in the absence of knowing there’s some incompatibility, my suggestion would be to use the ^ kind of version specifier: this just means it supports the version you gave plus all later releases with the same major version (first number).

So, ^1.0.0 || ^2.0.0 would mean that the module works on version 1.0.0 (and all later 1 versions) and on 2.0.0 (and all later 2 versions). We try to keep to the “contract” that things stay compatible as long as the Omeka major version is the same, so usually the carat ^ is the appropriate operator to use.

Oh, and, beyond the question of the supported Omeka S versions, the new 1.4.1 zip you uploaded looks fine, so you should expect it to be on omeka.org tomorrow.

Thanks - I’ll make the suggested change and push it out. The information you’ve provided here is very helpful as a supplement to the developer documentation.

And I have updated the omeka gulp file to clean the directory, update the dependencies, prepare the language template, clean the module with php-cs, and create a release on github automatically, with this command:

gulp release:module --module-name=XxxYyy

See the patch https://github.com/omeka/omeka-s/pull/1159

This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.