I am against this change. I am in favor of adding platforms via
package.json, however.
We need to version lock our dependencies in the CLI. Testing and bug
resolution will be impossible otherwise. (We did this for that reason.)
However, the Platforms don't need to be synchronized. Platforms can release
as they want and the CLI can pick them up as needs be BUT the versioning of
dependencies needs to be explicit.
The only way 'always grab latest' works is when master is pristine and all
development happens on topic branches only to be merged in when everything
works. That is not a capability we currently have.
"This makes it impossible to release new versions of platforms that would
be
usable with the same version of CLI." <--- this is a feature, not a bug!
When we want to bump the platforms we *should* have to bump the CLI as it
is a dependency.
On Thu, Jul 24, 2014 at 9:19 AM, Andrew Grieve <[email protected]>
wrote:
On Thu, Jul 24, 2014 at 10:40 AM, Chuck Lantz <[email protected]>
wrote:
To me it sounds like we're talking about something bigger than pinning:
What does a Cordova version actually mean?
When new macro-level "Cordova" features like splash screens and icons
support or perhaps coming up with a way to manage code signing and
packaging without going into native projects are released, we'll need
to
be
able to coordinate a release across a number of different platforms.
So,
the way I've always thought about this from and end user perspective
is:
Certainly having platforms at different versions will be a change from
what
we've had historically. Still, I think it will be for the better.
-Updating the first digit is done for major Cordova level features that
affect everyone - and force everyone to change
But what if only one platform has a change that requires action? Do we
not
bump the major then?, Or do we bump the major and users of other
platforms
discover it doesn't actually affect them.
-Updating the second digit is about incremental improvements that still
constitute new Cordova level features but may only support certain
platforms
-Updating the last digit ties to bug fixes, perf improvements, and other
things that do not have a direct effect on end users
Two questions:
-How will documentation work if platforms go to versions independent of
one another? For example, consider this:
Android goes to Cordova 3.7.0 one week
iOS goes to Cordova 3.7.0 two weeks later
Does the documentation for the same version update?
I think the easiest way is to just not version the docs. Just have them
always be up-to-date for all released platforms.
-Are we saying that there will never be shared infrastructure across
platforms that the CLI needs? Otherwise you could get in a situation
where
the CLI revs and only one or two platforms are actually supported.
Given
Cordova really is about cross-platform/multi-device development, is
that
a
message we want to send to end users? What about plugins?
The latest version of CLI must always support all plugins (even old
ones),
and all platform versions (even old ones). This (I believe), is already
the
case today, and is not too hard to maintain.
I also think this commits the community to testing the CLI across a
number
of different versions over time. The CLI would need to be validated
across
a number of different major and minor versions which increases the test
burden.
I believe this to already be the case. The current workflow is:
1. Install a platform (say, android 3.2)
2. Update CLI to 3.5.0
3. CLI now expected to work with version of platform you have installed.
4. Decide you want to update your platform via "cordova platform update
android"
5. Now, your project is at android 3.5.0
I would argue that plugins are a potential problem right now - the
moment
a core plugin drops support for a Cordova version that people are using
widely, I think we'll hear about it. However, in the case of a plugin,
it
is inherently multi-platform and its documentation and functionality
across
all platforms will update with one version change. I think that is the
issue with platforms - There needs to be a mechanism to communicate
that
something has changed across multiple platforms.
I think your plugin example is a great motivation for having things
versioned separately. If a plugin drops support for android-3.0.0, then
users are free to stick with an older version of the plugin that does
support it. I do conceded that our tooling is currently not great about
making this easy to do though.
Plugin features almost always get added one platform at a time. Likewise
with platform features. I don't think we should be striving to add
features
across all platforms at a time, because not all platforms even have
people
actively working on them. What's the gain in trying to synchronize them?
It
would only cause things to be released more slowly.
For example, we recently had icons and splashscreen support added to CLI
for some but not all platforms. This actually required no changes in
platforms, because platforms already supported both. This is a great
example of why we'd want CLI to not be pinned to platform versions.
Someone
running [email protected] would get icon support if they updated
their
version of CLI, and they wouldn't need to update their platform.
On the Android 4.0 churn vs fixes - this sounds more like a branching
problem that we should not pass on to end users.
-Chuck
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Andrew
Grieve
Sent: Thursday, July 24, 2014 6:47 AM
To: dev
Subject: Re: Proposal: remove platform versions from platfroms.js
I agree that the feature will make installing platforms less
predictable...
or at least, just as unpredictable as plugins.
It is a good idea to look at exactly what the benefits are though.
First - the benefits of removing the idea of a "cadence version":
- Android 4.0 is on the horizon, maybe iOS 4.0 as well. Does this mean
that when they are ready, we should force all platforms to jump to 4.0?
Wouldn't be too bad...
- But once at 4.0, what if Windows or Blackberry requires a major
release
a couple months later, move all platforms to 5.0?
- What if Android undergoes a lot of churn come 4.0, and wants to do 3
more bugfix releases within the first month after? Do we force all
platform's versions to be updated? If not, what does the cadence number
on
CLI look like?
- Cadence versioning forces us to try and release multiple platforms at
the same time.
- E.g. Jesse wants to release windows, but has been waiting for
Android
to be ready.
- If each platform just released when it was ready, and had separate
blog posts, I think we'd have a happier release process, and would
release
more often.
Now, we could do away with cadence version and still have CLI use the
version in its platforms.js file for each platform. So what does this
specific change of removing the pinning buy us?
- It will lighten the load of doing platform releases.
- It will make platforms and plugins both work in the same way.
On Wed, Jul 23, 2014 at 2:49 PM, Jesse <[email protected]>
wrote:
I agree, there are many cases where this will lead to complete
un-predictability, and it is still unclear who this 'feature'
benefits.
How can we guarantee that latest version of a newly added platform
supports all the same plugins of the previously added platforms?
I think ultimately the only benefit is to give us some flexibility
with release schedules, but I would much rather have us focus on just
releasing everything more often. Historically we have never been
able
to deliver a patched point release in under a month, so assuming we
can get back to releasing every month, all would be fine, and the
train could just keep rolling forwards. Predictably!
@purplecabbage
risingj.com
On Wed, Jul 23, 2014 at 10:59 AM, Parashuram Narasimhan (MS OPEN
TECH)
< [email protected]> wrote:
I was thinking platforms are devDependencies and plugins are
dependencies
:)
In a way, that’s how the bundling works - plugins are packaged with
the app, while platforms are only needed during development !!
-----Original Message-----
From: Anis KADRI [mailto:[email protected]]
Sent: Wednesday, July 23, 2014 10:54 AM
To: [email protected]
Subject: Re: Proposal: remove platform versions from platfroms.js
+1 for package.json for platforms. plugins might a bit trickier but
+still
doable, we could get rid of plugins/ but we somehow need to keep
track of them in node_modules/ (maybe use one of the 10 config
files
we have).
Platforms in package.json should cause no problems though,
add/remove platforms, pin/unpin versions if required.
On Wed, Jul 23, 2014 at 7:36 AM, Michal Mocny <[email protected]
wrote:
This sounds like a great topic for hangout Friday. Glad to have
a
concrete proposal / some counter arguments to discuss.
On Wed, Jul 23, 2014 at 10:22 AM, Mark Koudritsky
<[email protected]>
wrote:
Currently WebWorks ships specific versions of things.
If we had shipped unpinned versions of stuff, then eventually
we would have created projects which our UI wouldn't have
recognized as valid (because, they e.g. Didn't have a
".cordova", or a "hooks", or a
"merges"
or whichever things we had been using to determine if a
project was
valid).
As long as you continue to ship a version of cordova-backberry
bundled
with
WebWorks, it won't be affected by the change I propose. CLI
will
use that bundled version just like it does now using the
settings in .cordova/config.json. We do the same thing with
cca.
If in the future you decide to stop bundling cordova-blackberry
with WebWorks and switch to the npm published versions, I see
several good
ways
for doing that, but in any case, you will probably want to
expose the version (or range of versions) to use as a user
editable setting.
