cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Lantz <cla...@microsoft.com>
Subject RE: Proposal: remove platform versions from platfroms.js
Date Thu, 24 Jul 2014 14:40:22 GMT
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: 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
View raw message