Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-26842] CLI: Deprecate allowing no version to be set on a module in the tiapp

GitHub Issuen/a
TypeImprovement
PriorityNone
StatusOpen
ResolutionUnresolved
Affected Version/sn/a
Fix Version/sn/a
ComponentsCLI, Tooling
LabelsQ2, cb-tooling, engArch, roadmap2019, titaniumlib
ReporterEwan Harris
AssigneeEwan Harris
Created2019-02-21T14:41:50.000+0000
Updated2020-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

  1. Jan Vennemann 2019-02-21

    +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 * or latest 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.
  2. Ewan Harris 2019-02-21

    Yeah maybe we should just log a warning if someone is using a range like that to make it super explicit
  3. Jan Vennemann 2019-02-21

    Yup, i'm fine with that
  4. Christopher Williams 2019-09-17

    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.

JSON Source