Versioning of an Encapsulated Module

[retched]

I wanted to know what exactly is the practice of versioning of an encapsulated module.

Should only the files that were changed be included in that versions directory or should all files of the module, regardless if changed or not, be included?

[swguy]

Each version needs to be complete, with all required files.

[mc12345678]

Then either through instruction or new version action the next version should also be able to address the upgrade action preferably without failing because of the previous version.

[lat9]

Then either through instruction or new version action the next version should also be able to address the upgrade action preferably without failing because of the previous version.

That, IMO, goes without saying.

[mc12345678]

That, IMO, goes without saying.

IMO, all of this does. The answers are all a matter of preference and opinion. There's nothing of requirement in any of it. Do what you want or see best.

If others don't like what is created they'll just do things differently to get the result they want.

This is the way.

[retched]

Each version needs to be complete, with all required files.

So if I released say version 1.0.0 with a directory v1.0.0 and place that into the ZenCart plugins or a GitHub, couldn't I just rename that directory into version 1.1.0 release that in the plugins and GitHub?

In theory, the Plugins Directory and GitHub still have all the historical versions so if there is a problem with the newer version, the step back version can still be used?

[lat9]

So if I released say version 1.0.0 with a directory v1.0.0 and place that into the ZenCart plugins or a GitHub, couldn't I just rename that directory into version 1.1.0 release that in the plugins and GitHub?

In theory, the Plugins Directory and GitHub still have all the historical versions so if there is a problem with the newer version, the step back version can still be used?

Yep. FWIW, I start with the version-directory rename (so that existing files transition over to the new sub-directory) as one commit and then make the next-version updates on top of that.

[mc12345678]

So if I released say version 1.0.0 with a directory v1.0.0 and place that into the ZenCart plugins or a GitHub, couldn't I just rename that directory into version 1.1.0 release that in the plugins and GitHub?

In theory, the Plugins Directory and GitHub still have all the historical versions so if there is a problem with the newer version, the step back version can still be used?

Yep. FWIW, I start with the version-directory rename (so that existing files transition over to the new sub-directory) as one commit and then make the next-version updates on top of that.

For example the manifest.php file would need updating. An example of such is here: https://docs.zen-cart.com/dev/plugin...manifest-files
Even though that example doesn't align with the file structure folder name above it. E.g. file is stored under version 1.0.0 but the manifest shows version 3.0.0.