I agree with what Jesse said. That being said, despite talk to the contrary, I don't think any platform will sprint ahead. We've never seen any platform realistically have this happen, especially now that most features are encapsulated in plugins.
On Mon, Oct 6, 2014 at 9:02 PM, purplecabbage <purplecabb...@gmail.com> wrote: > This thread is now out of control, and hopefully this is the signal that > we need to have a hangout and dig into this. > > Thank you Leo for your insight, and representing the user. > > The system is elaborately complex, and I fear that > a) independent versions pushes these platform disparities firmly in the > users face > b) the matrix Peter eludes to would have 4 dimensions > > I would much rather see all platforms march forwards together, and get the > version bump regardless of what had changed. > This way we could at least say 7.5.4 means you get FeatureA for all > platforms, and FeatureB for platformY, > If we could get versioning/releasing down to a simple tag-all-repos, > log-all-changes, update+release all of everything, the system will at least > be more understandable. I also think this would make us better at > releasing, which we currently suck at ( no-one's fault ) I still want to > release every month, rain or shine, and whether or not we make a big or > little noise around any release would/could be decided by what made it in. > > Leo's suggestion, of advancing the CLI version number every time a > platform updates makes some sense too, if we aren't willing to just tag and > release all. > > This is a repost, as I apparently only sent this to Peter earlier. > > Sent from my iPhone > > > On Oct 6, 2014, at 3:37 PM, Smith, Peter <pet...@fast.au.fujitsu.com> > wrote: > > > > Super version flexibility == Super version confusion. > > > > The Cordova site seems in need of a kind of > Cordova/Platform/CLI/CorePlugin "version dependency matrix" which > officially documents what-works-with-what (e.g. what has passed the > official testing). Perhaps it would look something like the API support > matrix at > http://cordova.apache.org/docs/en/3.6.0/guide_support_index.md.html#Platform%20Support > . > > > > It might not be easy to do, but if the combined wit of Cordova > committers is unable to clearly document versioning dependencies then what > hope is there for end users to understand it? > > > > Peter > > > > -----Original Message----- > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > Andrew Grieve > > Sent: Sunday, 5 October 2014 5: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 > > > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB• È > [œÝXœØÜšX™K K[XZ[ ˆ ]‹][œÝXœØÜšX™P ÛÜ™ ݘK˜\ XÚ K›Ü™ÃB‘›Üˆ Y ] [Û˜[ > ÛÛ[X[™ Ë K[XZ[ ˆ ]‹Z [ ÛÜ™ ݘK˜\ XÚ K›Ü™ÃB > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
