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
Yes, It makes sense for created projects. But check #19483
We have to update nightly (-preview) versions for each version deployed for development purposes.
Still, I agree that created ABP projects should have specific version that is created with.
Maybe we can use wildcard for development and CLI puts the specific version while project creation steps.
Yes, It makes sense for created projects. But check #19483 We have to update nightly (-preview) versions for each version deployed for development purposes.
Still, I agree that created ABP projects should have specific version that is created with.
Maybe we can use wildcard for development and CLI puts the specific version while project creation steps.
I agree that we should specify the exact version of LeptonX Theme packages in abp template before every release. Doing this with CLI is easy but as we talked yesterday, this breaks the mentality of being able to release independent LeptonX releases and we would assume that the release schedule and cycle will be the same always. So, it occurs to me that the best option for now is to set the exact version for LeptonX Theme packages even before it's released (we should assume that it's released with the version that we specified).
what if the cli would get the latest compatible leptonx version for the corresponding abp version (by hitting some api or something) on creation and then replaces on project creation?
https://support.abp.io/QA/Questions/6981/Can%27t-build-project-if-new-version-is-released
@EngincanV
Can we change the Leptonx theme version to the exact version number instead of a wildcard when creating a new project?
what do you think?
The text was updated successfully, but these errors were encountered: