Support for multiple package versions

[maxguru]

Hi,

This is a really great package. I found it very useful.

However, one important feature is missing: the support for multiple versions of the package to be available for download. I understand this is not needed for updates to latest version but sometimes I need to send a link to users for downloading an older version of my plugin (because they need to downgrade for whatever reason). What I do currently is just upload a file of the older version with the version number appended to the name (plugin-1.2.3.zip) and that allows me to create URLs for these users. That is a bit of a hack. What do you think about having support for version argument (and changes to package folder structure) to be able to upgrade/downgrade to specific versions?

Thanks.

[YahnisElsts]

This is something that I've thought about before, but I haven't really had the time to implement it. What I had in mind was a directory layout like this:

/packages
    example-slug.zip
    another-example.zip
    /example-slug
        1.0.zip
        1.5.zip
    /another-example
        2.0.zip

Basically, you would still put the "current" version of each plugin in the packages directory, and the update server would automatically create a copy of each distinct version in a $slug subdirectory.

Thoughts?

[AlexPBrin]

I recommend naming them example-slug-1.0.zip or something to make it easy to keep track.

On Fri, Oct 23, 2020 at 3:15 AM Yahnis Elsts [email protected] wrote:

This is something that I've though about before, but I haven't really had the time to implement it. What I had in mind was a directory layout like this:

/packages example-slug.zip another-example.zip /example-slug 1.0.zip 1.5.zip /another-example 2.0.zip

Basically, you would still put the "current" version of each plugin in the packages directory, and the update server would automatically create a copy of each distinct version in a $slug subdirectory.

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/YahnisElsts/wp-update-server/issues/84#issuecomment-715042511, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7EMI7EYHOSQP3LDM73ZHTSMEUSFANCNFSM4SRRS2TQ .

--

• Alex Poirier-Brin* Associé et webmestre

[email protected] 819-341-8889 www.conceptc.ca

Voir contrat général de vente pour tout projet. https://conceptc.ca/cvg/

[YahnisElsts]

All of the version of a specific plugin would already be in a subdirectory named after that plugin, so it would be easy to figure out which plugin that is. I think that in this case adding the slug to the file name would be redundant, but I suppose it could be done.

[AlexPBrin]

It’s not so much for on server purpose but more so for once downloaded

On Fri, Oct 23, 2020 at 7:50 AM Yahnis Elsts [email protected] wrote:

All of the version of a specific plugin would already be in a subdirectory named after that plugin, so it would be easy to figure out which plugin that is. I think that in this case adding the slug to the file name would be redundant, but I suppose it could be done.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/YahnisElsts/wp-update-server/issues/84#issuecomment-715294190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH7EMIY4P6EAQJDRU7UMJADSMFUWXANCNFSM4SRRS2TQ .

--

• Alex Poirier-Brin* Associé et webmestre

[email protected] 819-341-8889 www.conceptc.ca

Voir contrat général de vente pour tout projet. https://conceptc.ca/cvg/

[maxguru]

One idea is to just disregard filenames and folder structure and read the file contents for slug and version information. That way, people can use whatever structure they like. The slug and version info can be cached and inotify can be used to update the cache when things change.

[YahnisElsts]

The server already reads the version information from the file contents and caches it for later use. I suppose it could also determine the slug that way (maybe based on the plugin folder name or the main PHP file name?), but this would break backwards compatibility and I'm not too enthusiastic about that.

There is no long-running server process, so I don't think inotify would be particularly useful here.

[maxguru]

I was just suggesting random ideas. My personal opinion is the packages directory structure shouldn't matter because all the information that is needed is in the zip files themselves, but it would be up to your decision and other constraints. incrontab can be used to trigger rescanning the packages directory after changes, but I guess it would be required to be installed on the system.