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

GitHub 'standard practice' can lead to issues in Foundry #27

Open
ggagnon76 opened this issue Jun 29, 2023 · 0 comments
Open

GitHub 'standard practice' can lead to issues in Foundry #27

ggagnon76 opened this issue Jun 29, 2023 · 0 comments

Comments

@ggagnon76
Copy link

The League's template instructions show how to create a release. GitHub offers 'common practice' instructions to create release tags, which suggests adding a v as a prefix to the tag version. See below:

image

This leads to problems because:

  1. the release action strips the v from the version and puts the result in the module.json. ex: v1.0 tag becomes 1.0 in the module.json
  2. there are no instructions for developers stating that the v should not be entered into the Foundry package submission form. The tag where they copy the module.json url still has the v. ex: v1.0
  3. once released in Foundry with a v in the version number, there is a mismatch between what Foundry thinks the version is and what the module.json says the version is. This results in constant prompts to the end users to update their modules.

I have personally been faced with this issue, and I have also seen others deal with this as well. It is inconvenient because removing the v is the solution, but because of how Foundry works, the developer has to inform the end users to first uninstall and then reinstall with the new version because vX.X will always be bigger/newer than X.X (where X's are numbers), so it's not possible for Foundry to offer the new version without the v as the newest version.

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

No branches or pull requests

1 participant