cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Treggiari, Leo" <>
Subject RE: Independent platform release summary
Date Sat, 04 Oct 2014 02:10:31 GMT
Here’s my concern regarding versions of things in Cordova.  As a developer I would use Cordova
to write portable applications.  Sure, maybe some developers use Cordova for other reasons,
but, to me at least, that seems to be the primary “draw”.

When writing a portable application, I want it to be as easy as possible to know that what
I want to use is supported everywhere I want to deploy my app.

Plugins have independent versions.  That makes sense.  As a developer I can see what the API
of plugin ‘FOO’ version ‘x.y.z’ is, and then look at a table to see where it is supported.
 That answers my questions about APIs and how I can use them in a portable manner.

I want the same to be true of ‘platform’ and Cordova CLI versions as much as possible.
 Maybe it is true already, but all of these independent releases and different platform version
numbers make me nervous.  For example, If a platform releases version 3.6.0, does that mean
that it supports the same set of features that other platforms that release 3.6.0 do?  The
major.minor.patch versioning scheme makes a great deal of sense.  However, imagine all platforms
started at version 3.0 with the same set of features.  Then 4 separate platforms each added
5 different features in an upward compatible manner and so they are now all at version 3.5.0.
 How does that help our users figure out how they can write a portable application?

Maybe there is a clear definition of what platform version numbers mean and I’m just not
aware of it.  Maybe a CLI release is not just a collection of the latest platform releases
and I’m just not aware of it.  It makes sense that platforms can release asynchronously,
but does the versioning scheme help the user figure out what is going on and when and where
they can expect common functionality across platforms?


From: [] On Behalf Of Brian LeRoux
Sent: Friday, October 03, 2014 5:29 PM
To: Andrew Grieve
Cc:; Marcel Kinard; Treggiari, Leo
Subject: Re: Independent platform release summary

I meant pinning all platforms to the cli (so an update to any of the platforms pushes everything
up one). Anyhow this is way hard to reason about. So its an improvement how again?
On Oct 3, 2014 4:55 PM, "Andrew Grieve" <<>>
Is pinning not what's driving this version number discussion?

Projects are generally made up of more plugins than platforms, but we don't bump the CLI each
time plugins are released. Maybe the simplest thing to do is just have the CLI version not
be influenced by platform versions at all.

Ideally, we'll finish up the work to write the platform versions in config.xml, and then users
won't accidentally update their platform versions without explicitly doing so in their config.xml
(or some equivalent CLI command that updates it).

On Fri, Oct 3, 2014 at 6:02 PM, Brian LeRoux <<>> wrote:
Maybe pinning platforms and the CLI wasn't so bad after all.
On Oct 3, 2014 2:34 PM, "Treggiari, Leo" <<>>

> I agree that this is, and will be, confusing.  It was confusing today in
> our own discussions in our own team (who are, in general, fairly Cordova
> savvy) to be talking about the Android store issue related to "Cordova
> 3.5.1".  E.g. what did it mean to be talking about "Cordova 3.5.1", and
> what would a user need to do to get the fix?  What I took away was that a
> user would need  Cordova CLI 3.5.0-0.2.7.  However, I wouldn't be surprised
> if you told me that was wrong...
> Anyway, a completely different (and possibly immediately dismissible)
> idea.  What if a Cordova CLI version number was the same as the highest
> version number of the platforms supported by that Cordova CLI version.
> E.g. if the latest highest platform version was Android 3.5.1, then the
> Cordova CLI version would be 3.5.1.  The supported other-platform version
> might be lower - e.g. Windows 3.4.2 (totally made up version number...).
> That doesn't instantly solve all problems.  What if the next platform
> release after Android 3.5.1 was Windows 3.4.3?  Cordova CLI can't remain at
> the highest version number.  So would Cordova CLI become 3.5.2 or 3.5.1-1?
> Should the Windows release be 3.5.2? Are there a specific set of features
> associated with a specific platform major version number?  It seems that a
> platform release named 3.x.y is expected to have a certain set of features
> implemented.  Is a platform release named 3.4.x expected to have a certain
> set of features and a platform named 3.5.x expected to have those features
> plus some additional feature?
> In general, what can a user expect these version numbers to mean.  E.g. if
> I as an app developer want to use a particular recently added feature on
> multiple platforms, how do I determine which versions of which platforms
> support the feature and which Cordova CLI version gives me what I want?
> Sorry, but it is confusing...
> Leo
> -----Original Message-----
> From: Marcel Kinard [<>]
> Sent: Friday, October 03, 2014 1:56 PM
> To:<>
> Subject: Re: Independent platform release summary
> If a bump to major indicates an API change, how is that visible to users?
> Do users look at the CLI version as "the version of Cordova", or are we
> expecting users to look at the version of every Cordova component to
> understand where majors got bumped? While I agree the latter is more
> correct technically, I think users have been and are currently assuming the
> former. It would take some education to switch that.
> On Oct 2, 2014, at 7:51 PM, Andrew Grieve <<>>
> > I don't think it's necessary to bump CLI major when platforms bump major.
> > Platforms and CLI are linked only superficially anyways.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:<>
> For additional commands, e-mail:<>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:<>
> For additional commands, e-mail:<>

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