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
When we publish a new NuGet package for OC extensions, we have to maintain Version in the extension manifest manually. This is not just necessary for when we use the extension from NuGet, but also when using it as a submodule. Thus, it's not trivial, since we can't just update the manifest for the NuGet publish but also need to do that in the repository.
Multiple extensions can be in a given repo, each with their own manifests.
We publish to NuGet by pushing a version tag. However, the version tag should already refer to a commit containing the same version in the manifest... So, perhaps we should move the tag during this process?
Note that not all projects we publish to NuGet are OC extensions; support for other projects should be kept.
But! Perhaps we don' actually need to keep manifest changes in the code; after all, it's mostly us who use the projects as submodules, and even if not, those users have the repo history at their fingertips. So, if the above is too complicated, we could get away with just setting the assembly version (what the build sets) as the manifest version. In this case, we should change all the version numbers in the Manifests to the default (when generated with the CLI template).
The text was updated successfully, but these errors were encountered:
Piedone
changed the title
Automate Orchard Core extension manifest version number update during NuGet publish
Automate Orchard Core extension manifest version number update during NuGet publish (OSOE-86)
Mar 9, 2022
When we publish a new NuGet package for OC extensions, we have to maintain
Version
in the extension manifest manually. This is not just necessary for when we use the extension from NuGet, but also when using it as a submodule. Thus, it's not trivial, since we can't just update the manifest for the NuGet publish but also need to do that in the repository.But! Perhaps we don' actually need to keep manifest changes in the code; after all, it's mostly us who use the projects as submodules, and even if not, those users have the repo history at their fingertips. So, if the above is too complicated, we could get away with just setting the assembly version (what the build sets) as the manifest version. In this case, we should change all the version numbers in the Manifests to the default (when generated with the CLI template).
The text was updated successfully, but these errors were encountered: