cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Thu, 24 Jul 2014 20:00:29 GMT
On Thu, Jul 24, 2014 at 3:49 PM, Brian LeRoux <b@brian.io> 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 <agrieve@chromium.org>
> 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 <mmocny@chromium.org>
> 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 <b@brian.io> 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 <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