cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Thu, 24 Jul 2014 17:38:49 GMT
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 <agrieve@chromium.org> wrote:

> On Thu, Jul 24, 2014 at 10:40 AM, Chuck Lantz <clantz@microsoft.com>
> 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 cordova-android@3.1.0 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: agrieve@google.com [mailto:agrieve@google.com] 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 <purplecabbage@gmail.com> 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)
> > > < panarasi@microsoft.com> 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:anis.kadri@gmail.com]
> > > > Sent: Wednesday, July 23, 2014 10:54 AM
> > > > To: dev@cordova.apache.org
> > > > 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 <mmocny@chromium.org>
> > > 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
> > > > > <kamrik@google.com>
> > > > > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message