On Thu, Jul 24, 2014 at 3:49 PM, Brian LeRoux <[email protected]> wrote: > - ya I don't care at all about whatever we want the versioning scheme to be > > I don't see much benefit from this: > > "cordova platform add android@NEXT_VERSION" > > I'd rather see ppl update their tool to the next version of the CLI. >
My thinking there was that we'll be able to announce platform updates without waiting for a tools release to happen. > > > > > On Thu, Jul 24, 2014 at 12:36 PM, Andrew Grieve <[email protected]> > wrote: > > > How about discussing dropping the CAD-SEM version of CLI, and just have > > SEM? > > > > Probably it'd still be good to go over what *exactly* the platform > release > > process should look like. E.g.: > > - Any platform can be released at any time > > - If it requires an update to cordova.js, then create a new cordova.js > > version. > > - Create a blog post just for your platform > > - Tell users to try it out via "cordova platform add android@NEXT_VERSION > " > > - Next time tools release happens, CLI will have its default platform > > version updated to include the new platform release. > > > > > > On Thu, Jul 24, 2014 at 3:18 PM, Michal Mocny <[email protected]> > wrote: > > > > > OOOOhhh, Brain you meant cordova-cli's package.json, not the project > > > workspaces! I like that. I like that you can create a project while > > > offline that way. I'm also with David/Brian/Others that CLI can have a > > > default pinned version set, yet we still get cordova platform version > > > independance. > > > > > > I thought we were proposing creating a package.json as part of "cordova > > > create" alongside config.xml, which I was really O_o about. (I think > > this > > > is a likely direction we may end up, but not just nilly willy). > > > > > > Glad we are coming to agreement, but now we wont have anything to > discuss > > > Friday ;) > > > > > > -Michal > > > > > > > > > On Thu, Jul 24, 2014 at 2:56 PM, Brian LeRoux <[email protected]> wrote: > > > > > > > totally agree. the cli package.json can capture which versions of the > > > > platforms it needs. the platforms can release with reckless abandon > > > > > > > > (maybe we'll even hit THREE times this year! ;) > > > > > > > > > > > > On Thu, Jul 24, 2014 at 11:17 AM, David Kemp <[email protected]> > > > wrote: > > > > > > > > > It seems to me that: > > > > > 1) to make our users happy and get them to consider using newer > > > versions, > > > > > we need to have the perception of stability. Nice clean, well > tested, > > > > > co-ordinated releases are a good way to get that. For that reason, > I > > > > think > > > > > a method of providing a 'pinned' release set for the end user is a > > good > > > > way > > > > > to deliver that. > > > > > 2) to make it easy and fast for the various platform contributors > to > > > > > release new stuff, we need independent platform versioning. That > > would > > > > > allow platforms to move ahead separately - as long as all tooling > is > > > > > backward compatible. > > > > > > > > > > We should be able to do both. > > > > > > > > > > > > > > > > > > > > On Thu, Jul 24, 2014 at 1:38 PM, Brian LeRoux <[email protected]> wrote: > > > > > > > > > > > I am against this change. I am in favor of adding platforms via > > > > > > package.json, however. > > > > > > > > > > > > We need to version lock our dependencies in the CLI. Testing and > > bug > > > > > > resolution will be impossible otherwise. (We did this for that > > > reason.) > > > > > > However, the Platforms don't need to be synchronized. Platforms > can > > > > > release > > > > > > as they want and the CLI can pick them up as needs be BUT the > > > > versioning > > > > > of > > > > > > dependencies needs to be explicit. > > > > > > > > > > > > The only way 'always grab latest' works is when master is > pristine > > > and > > > > > all > > > > > > development happens on topic branches only to be merged in when > > > > > everything > > > > > > works. That is not a capability we currently have. > > > > > > > > > > > > "This makes it impossible to release new versions of platforms > that > > > > would > > > > > > be > > > > > > usable with the same version of CLI." <--- this is a feature, > not a > > > > bug! > > > > > > When we want to bump the platforms we *should* have to bump the > CLI > > > as > > > > it > > > > > > is a dependency. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 24, 2014 at 9:19 AM, Andrew Grieve < > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > > > On Thu, Jul 24, 2014 at 10:40 AM, Chuck Lantz < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > To me it sounds like we're talking about something bigger > than > > > > > pinning: > > > > > > > > What does a Cordova version actually mean? > > > > > > > > > > > > > > > > When new macro-level "Cordova" features like splash screens > and > > > > icons > > > > > > > > support or perhaps coming up with a way to manage code > signing > > > and > > > > > > > > packaging without going into native projects are released, > > we'll > > > > need > > > > > > to > > > > > > > be > > > > > > > > able to coordinate a release across a number of different > > > > platforms. > > > > > > So, > > > > > > > > the way I've always thought about this from and end user > > > > perspective > > > > > > is: > > > > > > > > > > > > > > > > > > > > > Certainly having platforms at different versions will be a > change > > > > from > > > > > > what > > > > > > > we've had historically. Still, I think it will be for the > better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Updating the first digit is done for major Cordova level > > > features > > > > > that > > > > > > > > affect everyone - and force everyone to change > > > > > > > > > > > > > > > But what if only one platform has a change that requires > action? > > Do > > > > we > > > > > > not > > > > > > > bump the major then?, Or do we bump the major and users of > other > > > > > > platforms > > > > > > > discover it doesn't actually affect them. > > > > > > > > > > > > > > > > > > > > > > -Updating the second digit is about incremental improvements > > that > > > > > still > > > > > > > > constitute new Cordova level features but may only support > > > certain > > > > > > > platforms > > > > > > > > > > > > > > -Updating the last digit ties to bug fixes, perf improvements, > > and > > > > > other > > > > > > > > things that do not have a direct effect on end users > > > > > > > > > > > > > > > > > > > > > > Two questions: > > > > > > > > -How will documentation work if platforms go to versions > > > > independent > > > > > of > > > > > > > > one another? For example, consider this: > > > > > > > > > > > > > > > > Android goes to Cordova 3.7.0 one week > > > > > > > > iOS goes to Cordova 3.7.0 two weeks later > > > > > > > > > > > > > > > > > > > > > > Does the documentation for the same version update? > > > > > > > > > > > > > > > > > > > > > > I think the easiest way is to just not version the docs. Just > > have > > > > them > > > > > > > always be up-to-date for all released platforms. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Are we saying that there will never be shared infrastructure > > > > across > > > > > > > > platforms that the CLI needs? Otherwise you could get in a > > > > situation > > > > > > > where > > > > > > > > the CLI revs and only one or two platforms are actually > > > supported. > > > > > > Given > > > > > > > > Cordova really is about cross-platform/multi-device > > development, > > > is > > > > > > that > > > > > > > a > > > > > > > > message we want to send to end users? What about plugins? > > > > > > > > > > > > > > > > > > > > > > The latest version of CLI must always support all plugins (even > > old > > > > > > ones), > > > > > > > and all platform versions (even old ones). This (I believe), is > > > > already > > > > > > the > > > > > > > case today, and is not too hard to maintain. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also think this commits the community to testing the CLI > > > across a > > > > > > > number > > > > > > > > of different versions over time. The CLI would need to be > > > validated > > > > > > > across > > > > > > > > a number of different major and minor versions which > increases > > > the > > > > > test > > > > > > > > burden. > > > > > > > > > > > > > > > > > > > > > > I believe this to already be the case. The current workflow is: > > > > > > > > > > > > > > 1. Install a platform (say, android 3.2) > > > > > > > 2. Update CLI to 3.5.0 > > > > > > > 3. CLI now expected to work with version of platform you have > > > > > installed. > > > > > > > 4. Decide you want to update your platform via "cordova > platform > > > > update > > > > > > > android" > > > > > > > 5. Now, your project is at android 3.5.0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would argue that plugins are a potential problem right now > - > > > the > > > > > > moment > > > > > > > > a core plugin drops support for a Cordova version that people > > are > > > > > using > > > > > > > > widely, I think we'll hear about it. However, in the case > of a > > > > > plugin, > > > > > > > it > > > > > > > > is inherently multi-platform and its documentation and > > > > functionality > > > > > > > across > > > > > > > > all platforms will update with one version change. I think > > that > > > is > > > > > the > > > > > > > > issue with platforms - There needs to be a mechanism to > > > communicate > > > > > > that > > > > > > > > something has changed across multiple platforms. > > > > > > > > > > > > > > > > > > > > > > I think your plugin example is a great motivation for having > > things > > > > > > > versioned separately. If a plugin drops support for > > android-3.0.0, > > > > then > > > > > > > users are free to stick with an older version of the plugin > that > > > does > > > > > > > support it. I do conceded that our tooling is currently not > great > > > > about > > > > > > > making this easy to do though. > > > > > > > > > > > > > > Plugin features almost always get added one platform at a time. > > > > > Likewise > > > > > > > with platform features. I don't think we should be striving to > > add > > > > > > features > > > > > > > across all platforms at a time, because not all platforms even > > have > > > > > > people > > > > > > > actively working on them. What's the gain in trying to > > synchronize > > > > > them? > > > > > > It > > > > > > > would only cause things to be released more slowly. > > > > > > > > > > > > > > For example, we recently had icons and splashscreen support > added > > > to > > > > > CLI > > > > > > > for some but not all platforms. This actually required no > changes > > > in > > > > > > > platforms, because platforms already supported both. This is a > > > great > > > > > > > example of why we'd want CLI to not be pinned to platform > > versions. > > > > > > Someone > > > > > > > running [email protected] would get icon support if they > > > updated > > > > > > their > > > > > > > version of CLI, and they wouldn't need to update their > platform. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On the Android 4.0 churn vs fixes - this sounds more like a > > > > branching > > > > > > > > problem that we should not pass on to end users. > > > > > > > > > > > > > > > > -Chuck > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of > > > > > > Andrew > > > > > > > > Grieve > > > > > > > > Sent: Thursday, July 24, 2014 6:47 AM > > > > > > > > To: dev > > > > > > > > Subject: Re: Proposal: remove platform versions from > > platfroms.js > > > > > > > > > > > > > > > > I agree that the feature will make installing platforms less > > > > > > > predictable... > > > > > > > > or at least, just as unpredictable as plugins. > > > > > > > > > > > > > > > > It is a good idea to look at exactly what the benefits are > > > though. > > > > > > > > > > > > > > > > First - the benefits of removing the idea of a "cadence > > version": > > > > > > > > - Android 4.0 is on the horizon, maybe iOS 4.0 as well. Does > > this > > > > > mean > > > > > > > > that when they are ready, we should force all platforms to > jump > > > to > > > > > 4.0? > > > > > > > > Wouldn't be too bad... > > > > > > > > - But once at 4.0, what if Windows or Blackberry requires a > > major > > > > > > release > > > > > > > > a couple months later, move all platforms to 5.0? > > > > > > > > - What if Android undergoes a lot of churn come 4.0, and > wants > > to > > > > do > > > > > 3 > > > > > > > > more bugfix releases within the first month after? Do we > force > > > all > > > > > > > > platform's versions to be updated? If not, what does the > > cadence > > > > > number > > > > > > > on > > > > > > > > CLI look like? > > > > > > > > - Cadence versioning forces us to try and release multiple > > > > platforms > > > > > at > > > > > > > > the same time. > > > > > > > > - E.g. Jesse wants to release windows, but has been waiting > > for > > > > > > Android > > > > > > > > to be ready. > > > > > > > > - If each platform just released when it was ready, and had > > > > > separate > > > > > > > > blog posts, I think we'd have a happier release process, and > > > would > > > > > > > release > > > > > > > > more often. > > > > > > > > > > > > > > > > Now, we could do away with cadence version and still have CLI > > use > > > > the > > > > > > > > version in its platforms.js file for each platform. So what > > does > > > > this > > > > > > > > specific change of removing the pinning buy us? > > > > > > > > - It will lighten the load of doing platform releases. > > > > > > > > - It will make platforms and plugins both work in the same > way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 23, 2014 at 2:49 PM, Jesse < > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > > > I agree, there are many cases where this will lead to > > complete > > > > > > > > > un-predictability, and it is still unclear who this > 'feature' > > > > > > benefits. > > > > > > > > > > > > > > > > > > How can we guarantee that latest version of a newly added > > > > platform > > > > > > > > > supports all the same plugins of the previously added > > > platforms? > > > > > > > > > > > > > > > > > > I think ultimately the only benefit is to give us some > > > > flexibility > > > > > > > > > with release schedules, but I would much rather have us > focus > > > on > > > > > just > > > > > > > > > releasing everything more often. Historically we have > never > > > been > > > > > > able > > > > > > > > > to deliver a patched point release in under a month, so > > > assuming > > > > we > > > > > > > > > can get back to releasing every month, all would be fine, > and > > > the > > > > > > > > > train could just keep rolling forwards. Predictably! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @purplecabbage > > > > > > > > > risingj.com > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 23, 2014 at 10:59 AM, Parashuram Narasimhan (MS > > > OPEN > > > > > > TECH) > > > > > > > > > < [email protected]> wrote: > > > > > > > > > > > > > > > > > > > I was thinking platforms are devDependencies and plugins > > are > > > > > > > > > > dependencies > > > > > > > > > > :) > > > > > > > > > > > > > > > > > > > > In a way, that’s how the bundling works - plugins are > > > packaged > > > > > with > > > > > > > > > > the app, while platforms are only needed during > development > > > !! > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Anis KADRI [mailto:[email protected]] > > > > > > > > > > Sent: Wednesday, July 23, 2014 10:54 AM > > > > > > > > > > To: [email protected] > > > > > > > > > > Subject: Re: Proposal: remove platform versions from > > > > platfroms.js > > > > > > > > > > > > > > > > > > > > +1 for package.json for platforms. plugins might a bit > > > trickier > > > > > but > > > > > > > > > > +still > > > > > > > > > > doable, we could get rid of plugins/ but we somehow need > to > > > > keep > > > > > > > > > > track of them in node_modules/ (maybe use one of the 10 > > > config > > > > > > files > > > > > > > > we have). > > > > > > > > > > Platforms in package.json should cause no problems > though, > > > > > > > > > > add/remove platforms, pin/unpin versions if required. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 23, 2014 at 7:36 AM, Michal Mocny < > > > > > [email protected] > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > This sounds like a great topic for hangout Friday. > Glad > > to > > > > > have > > > > > > a > > > > > > > > > > > concrete proposal / some counter arguments to discuss. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jul 23, 2014 at 10:22 AM, Mark Koudritsky > > > > > > > > > > > <[email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Currently WebWorks ships specific versions of > things. > > > > > > > > > > > > > If we had shipped unpinned versions of stuff, then > > > > > eventually > > > > > > > > > > > > > we would have created projects which our UI > wouldn't > > > have > > > > > > > > > > > > > recognized as valid (because, they e.g. Didn't > have a > > > > > > > > > > > > > ".cordova", or a "hooks", or a > > > > > > > > > > > "merges" > > > > > > > > > > > > > or whichever things we had been using to determine > > if a > > > > > > > > > > > > > project was > > > > > > > > > > > > valid). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As long as you continue to ship a version of > > > > > cordova-backberry > > > > > > > > > > > > bundled > > > > > > > > > > > with > > > > > > > > > > > > WebWorks, it won't be affected by the change I > propose. > > > CLI > > > > > > will > > > > > > > > > > > > use that bundled version just like it does now using > > the > > > > > > > > > > > > settings in .cordova/config.json. We do the same > thing > > > with > > > > > > cca. > > > > > > > > > > > > > > > > > > > > > > > > If in the future you decide to stop bundling > > > > > cordova-blackberry > > > > > > > > > > > > with WebWorks and switch to the npm published > > versions, I > > > > see > > > > > > > > > > > > several good > > > > > > > > > > > ways > > > > > > > > > > > > for doing that, but in any case, you will probably > want > > > to > > > > > > > > > > > > expose the version (or range of versions) to use as a > > > user > > > > > > > > editable setting. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
