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:
-Updating the first digit is done for major Cordova level features that affect
everyone - and force everyone to change
-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?
-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?
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 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.
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.
> > > >
> > >
> >
>
