cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Thu, 24 Jul 2014 13:47:19 GMT
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