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.
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.
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: