[TIMOB-26842] CLI: Deprecate allowing no version to be set on a module in the tiapp
GitHub Issue | n/a |
Type | Improvement |
Priority | None |
Status | Open |
Resolution | Unresolved |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | CLI, Tooling |
Labels | Q2, cb-tooling, engArch, roadmap2019, titaniumlib |
Reporter | Ewan Harris |
Assignee | Ewan Harris |
Created | 2019-02-21T14:41:50.000+0000 |
Updated | 2020-03-06T21:34:29.000+0000 |
Description
Description
Currently today, the "version" property of a module tag in the tiapp.xml does not require a value to be set. This means that during a build, the latest version of a module will be pulled in (as long as the minsdk in the manifest is satisfied).
This means that if we wish to make changes to a module that are breaking changes, but do not require a minsdk change (for example the recent changes to ti.facebook TIMOB-26823) we cannot do so unless it's a semver major release of the SDK, and aligning any breaking changes across (at an eyeball) 10 modules distributed via the SDK is nigh on impossible in my opinion. It is important to enable ourselves to do this because it's possible that a breaking change might be needed by a user to adapt to a 3rd party change (for example a breaking change in a ti.facebook that is required to be in place by facebook by a certain date)
I propose that we do the following:
* Deprecate support for no version specified in a module tag, with a view to erroring completely in 9
* Allow support for semver ranges in a version tag
** (flag) Do we disallow ranges like "*" and "latest" to prevent users opting into this?
Doing this would allow us to ship updates to modules that are breaking changes without requiring an semver major SDK version bump.
Comments
JSON Source
+1 for this! I don't think we should disallow any semver ranges. If we make the version field required and users decide to opt in for
*
orlatest
then they should know what they are doing. A note what this means and that it can possibly pull in breaking changes when updating the SDK should be in our docs, though.Yeah maybe we should just log a warning if someone is using a range like that to make it super explicit
Yup, i'm fine with that
Sometimes we're forced by third parties to ship breaking module updates. We should actively discourage default of "latest" for modules and encourage use of exact version numbers.