Leo - that was a very well thought out summary of the state of things! I agree that from a user perspective, it would be easier to understand and reason about things if platform versions corresponded to things that platforms support in a x-platform sense.
I think in practice it's just not feasible to co-ordinate platforms in this way. E.g. Android wants to add support for feature X, but iOS is busy trying to make iOS 8 work. Should Android disable the feature until it rises to the top of the priority list for all other platforms? The answer, in my opinion, is that we just need to document "feature X works on Android as of FOO, iOS as of BAR" On Sat, Oct 4, 2014 at 4:05 PM, Treggiari, Leo <leo.treggi...@intel.com> wrote: > >To the best of my knowledge, the version numbers of platforms do not > signify that platforms have the >same functionality. Version numbers for > plugins also don't really do this - many plugins have different > >capabilities on different platforms even at the same version number. > > > > If you tell me that is true then I certainly believe you. My question is, > is this a good thing? I.e. Is it the best way to help developers who want > to write portable hybrid applications or is it just the way things evolved? > > > > I just went to http://cordova.apache.org/. It has a button for “Download > Cordova version 3.6.0”. What mental model should I be using to understand > what I am going to get? The page also gives me a pointer to the > documentation - http://cordova.apache.org/docs/en/3.6.0/. > > > > Note that I’m focusing on the Cross-platform (CLI) workflow. I currently > don’t see why I should care about the Platform-centered workflow. Why? > Because my own gut, and what I have heard from speakers at conferences, > tells me that if I’m writing for a single platform, I should stick to the > native programming environment. Just an aside to explain where I’m coming > from. > > > > Some of my statements below could be wrong and please correct me when they > are. > > > > Plugins implement the native device functionality. You point out that > they can have different capabilities on different platforms. I understand > that this must be the case – i.e. if one platform has a capability that > others don’t, there is no logical reason to make that functionality > unavailable until all platforms can support it. However, if my goal is a > portable application, I hope this is the exception and not the rule. As > long as the documentation clearly points out the platform differences, > that’s OK. This is from the first page of the Cordova documentation: > “Ideally, the JavaScript APIs to that native code are consistent across > multiple device platforms.” All I can say is 1+. > > > > What functionality does a Cordova CLI “platform” provide? > > · Cordova “Applications execute within wrappers targeted to each > platform”. This is clearly platform specific, but to the app developer > this should be “invisible”. > > · Build with a platform SDK which supports a specific set of > platform versions. The build functionality should be ‘opaque’ as long as > the developer has the correct prerequisites correctly installed. It is > clearly platform specific as to which version(s) of the platform (OS) a > Cordova platform supports. > > · Supports the functionality specified in config.xml: “The > config.xml file contains important metadata needed to generate and > distribute the application.” The config.xml specification defines > cross-platform configuration options. I suggest that these cross-platform > options defined by a Cordova version (e.g. 3.6) should be supported by all > platforms that release a 3.6.x version. Config.xml seems to identify the > functionality “contract” for a platform version, over and above the > wrappers and build functionality which are just assumed to work. This may > already be the case. Just like with plugin-in APIs, platforms may have > platform specific functionality. Again this is OK and should be well > documented. Again, when functionality can be abstracted using a common > paradigm, that helps developers create portable applications more easily. > > · Support an embedded WebView: This seems platform specific at > this time and that is OK. Maybe it will evolve over time into more > portable functionality. > > > > What functionality does Cordova CLI itself provide? It defines a workflow > that pulls together plugins and platforms and drives the development > process for a portable hybrid application. > > · Support for platform specific code – merges > > · Support for developer specific workflow additions - hooks > > So, should a change in the Cordova CLI version mean a change in the > workflow functionality? > > > > Platforms and/or Cordova CLI have a connection to the plugin.xml > specification, correct? That is, if a new capability is added to > plugin.xml, then a newer version of something is required to process it. > What else have I missed which drives functionality/version changes (leaving > out ‘patch’ versions)? > > > > Leo > > > > > > *From:* agri...@google.com [mailto:agri...@google.com] *On Behalf Of *Andrew > Grieve > *Sent:* Saturday, October 04, 2014 11:05 AM > *To:* Treggiari, Leo > *Cc:* Brian LeRoux; Andrew Grieve; dev@cordova.apache.org; Marcel Kinard > > *Subject:* Re: Independent platform release summary > > > > To the best of my knowledge, the version numbers of platforms do not > signify that platforms have the same functionality. Version numbers for > plugins also don't really do this - many plugins have different > capabilities on different platforms even at the same version number. > > > > For example, whitelists mean different things on different platforms. > Another example is that different platforms added support for ArrayBuffers > over the exec() bridge at different times. Historically - platform version > numbers just mean that they were all released at the same time. > > > > For the most part, platforms keep changing to keep up with OS changes, but > almost never are there features that are added across all platforms at the > same time. > > > > > > > > > > On Fri, Oct 3, 2014 at 10:10 PM, Treggiari, Leo <leo.treggi...@intel.com> > wrote: > > 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? > > > > Leo > > > > *From:* brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] *On Behalf > Of *Brian LeRoux > *Sent:* Friday, October 03, 2014 5:29 PM > *To:* Andrew Grieve > *Cc:* dev@cordova.apache.org; 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" <agri...@chromium.org> wrote: > > 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 <b...@brian.io> wrote: > > Maybe pinning platforms and the CLI wasn't so bad after all. > > On Oct 3, 2014 2:34 PM, "Treggiari, Leo" <leo.treggi...@intel.com> wrote: > > > 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 [mailto:cmarc...@gmail.com] > > Sent: Friday, October 03, 2014 1:56 PM > > To: dev@cordova.apache.org > > 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 <agri...@chromium.org> wrote: > > > > > 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: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > >
