cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Thu, 24 Jul 2014 18:56:19 GMT
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 <drkemp@chromium.org> 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 <b@brian.io> 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 <agrieve@chromium.org>
> > wrote:
> >
> > > On Thu, Jul 24, 2014 at 10:40 AM, Chuck Lantz <clantz@microsoft.com>
> > > 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 cordova-android@3.1.0 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: agrieve@google.com [mailto:agrieve@google.com] 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 <purplecabbage@gmail.com>
> > 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)
> > > > > < panarasi@microsoft.com> 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:anis.kadri@gmail.com]
> > > > > > Sent: Wednesday, July 23, 2014 10:54 AM
> > > > > > To: dev@cordova.apache.org
> > > > > > 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 <
> mmocny@chromium.org
> > >
> > > > > 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
> > > > > > > <kamrik@google.com>
> > > > > > > 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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