Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for multiple package versions #84

Open
maxguru opened this issue Oct 15, 2020 · 7 comments
Open

Support for multiple package versions #84

maxguru opened this issue Oct 15, 2020 · 7 comments

Comments

@maxguru
Copy link

maxguru commented Oct 15, 2020

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
Copy link
Owner

YahnisElsts commented Oct 23, 2020

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
Copy link

AlexPBrin commented Oct 23, 2020 via email

@YahnisElsts
Copy link
Owner

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
Copy link

AlexPBrin commented Oct 23, 2020 via email

@maxguru
Copy link
Author

maxguru commented Oct 23, 2020

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
Copy link
Owner

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
Copy link
Author

maxguru commented Oct 23, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants