Hi Peter

Is there a way we can make it so its NOT possible to upgrade to a new release.

I have two modules at the moment, catalog and catalog_ex, and I want to release a new version of catalog that contains catalog_ex. Now you can see the problem, because even if I remove the catalog_ex->catalog dependency, I still cannot prevent users from simply clicking upgrade on the catalog module and then things break completely.

Perhaps if there was an option [ x] prevent upgrade from previous version, then I can release the new version as a standalone.

Alternatively I could just create a new extension name, but that doesn't really help, because it still is a newer version of catalog.

And if I do click upgrade, then can I create some actions to zip up the catalog_ex folder, so that it no longer presents a problem with duplicate dca/ entries, etc. Do I do that in the install.php file for the package? I'm not sure if this is documented somewhere, as I couldn't find it easily.

I dont understand the problem completely, so lets try to sum it up:

- Current version catalog_ex depends on current version of catalog
- There will be a new version of catalog, but no more new version of catalog_ex
- If somebody upgrades to the new version of catalog, all needed files will be contained in the catalogs folder, including those files that formerly were in catalog-ex folder, right?

Now why exactly would that upgrade to new catalog break everything? I can only see the problem that there are still some files on the (now superfluous) catalog_ex folder. So somebody who upgrades to new catalog should at same time delete catalog_ex?

thyon:

And if I do click upgrade, then can I create some actions to zip up the catalog_ex folder, so that it no longer presents a problem with duplicate dca/ entries, etc. Do I do that in the install.php file for the package? I'm not sure if this is documented somewhere, as I couldn't find it easily.

Such a hook is planed for future version of the repository, but not implemented yet.

You could maybe meanwhile first check if catalog_ex is installed, then if it is disabled by unserializing $GLOBALS['TL_CONFIG']['inactiveModules'], and finally if necessary update the inactive modules list $GLOBALS['TL_CONFIG']['inactiveModules'] (save localconfig using Config::save). Since checking for directory existence and reading the inactive modules is a very checp operation, this could be done every time you module gets access. When a hook gets available in future repository version you can then change.