cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Independent platform release summary
Date Mon, 06 Oct 2014 19:40:28 GMT
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.treggiari@intel.com>
wrote:

>  Hi Andrew,
>
>
>
> Thanks for reading and responding.  I guess time will tell whether users
> stumble over this or not.
>
>
>
> Leo
>
>
>
> *From:* agrieve@google.com [mailto:agrieve@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.treggiari@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:* agrieve@google.com [mailto:agrieve@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.treggiari@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.leroux@gmail.com [mailto:brian.leroux@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" <agrieve@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.treggiari@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:cmarcelk@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 <agrieve@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-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
>
>
>
>
>
>

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