You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just checked out this registry for fpm and noticed some rough edges. It is somewhat related to #1, but maybe worth a separate issue.
Specifying a project with multiple releases quickly gets redundant, imagine a package which releases on a regular basis, keeping the registry data up-to-date will quickly become a copy-and-paste approach
The other idea I had was that it would automatically convert the version number "3.1" to a tag "v3.1". But others thought that might be too fragile, so we haven't implemented it. I still think it's a good idea to make this simpler and we should implement it. Your example could become:
It is not clear if a version number will always match the version tag with a v prefixed, some projects use just the version number as a tag, some always prefix with v or with the project name. I even saw projects switching between releases back and forth. No doubt this would be fragile. But the other way round, specifying the tag as target and extracting the version number from the fpm.toml would certainly work, the registry has to fetch the package file anyway for validation.
I just checked out this registry for fpm and noticed some rough edges. It is somewhat related to #1, but maybe worth a separate issue.
Specifying a project with multiple releases quickly gets redundant, imagine a package which releases on a regular basis, keeping the registry data up-to-date will quickly become a copy-and-paste approach
A slight improvement in my opinion would be to allow specifying the upstream URL in the project section and allow to overwrite it per version basis.
The text was updated successfully, but these errors were encountered: