To be clear - I think they do stumble. I just don't see a viable path to make it better.
On Mon, Oct 6, 2014 at 3:22 PM, Treggiari, Leo <leo.treggi...@intel.com> wrote: > Hi Andrew, > > > > Thanks for reading and responding. I guess time will tell whether users > stumble over this or not. > > > > Leo > > > > *From:* agri...@google.com [mailto:agri...@google.com] *On Behalf Of *Andrew > Grieve > *Sent:* Monday, October 06, 2014 12:12 PM > *To:* Treggiari, Leo > *Cc:* Andrew Grieve; Brian LeRoux; dev@cordova.apache.org; Marcel Kinard > > *Subject:* Re: Independent platform release summary > > > > 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 > > > > > > > > > > >
