cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Releases in a 3.0 World
Date Wed, 07 Aug 2013 20:27:14 GMT
On Wed, Aug 7, 2013 at 12:49 PM, Brian LeRoux <b@brian.io> wrote:

> I think keeping the cadence on the core platforms makes sense. That is
> where the bulk of logic lives, it is susceptible to 3rd party issues
> like new iDEs and SDKs, and having that regular cadence in lockstep
> makes issue tracking easier to discuss with the community.
>
> Plugins and CLI tools I think we should just ship continuously. The
> only question that remains in the 'how' of that is versioning. Mike
> Brookes has advocated semver schema here wherein we version platforms
> separately from the tools using a compound version number. An example
> of this might be 3.0.0-0.14.3 wherein 3.0.0 represents our platforms
> while 0.14.3 represents the CLI tool itself.
>
> I am not a fan of semver as that it is almost wholly conceptual and
> thusly non-enforcable. It is a nice framework for reasoning but ppl
> ignore half of the rules devaluing its promise. Also, it was conceived
> originally as a solution for globally installed packages which isn't
> really an issue in modern situations. That said, having a versioning
> scheme that exists, is well documented, and generally understood are
> all positives for me. It would mean our deprec policy could push the
> version numbers up quickly (which is fine).
>
> It is important to remember the reason for versioning, for our case,
> is issue tracking and resolution but as our ecosystem grows it will
> also play a very important role in dependency management. Especially
> between plugins. More discreet versions: the better.
>
> (Andrew I think you should start a separate thread about killing off
> cordova-js and moving into platforms for loading now that we have
> mostly removed the plugins. I am very much in favor!)
>
Yeah, I regretted this almost immediately. Since this thread is focusing on
the platforms, I'll do just that!


>
>
> On Tue, Aug 6, 2013 at 1:43 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> > Want to have this as a discussion starter.
> >
> > We've previously established that:
> > 1. Releases for plugman & CLI will not be tied to platform releases
> > 2. Releases to plugins will not be tied to platform releases
> >
> > That's not to say we shouldn't sometime co-ordinate them with platform
> > releases, but I think there would need to be a compelling reason to
> couple
> > them.
> >
> > I'm wondering if it makes sense to not tie platform releases together
> > either? E.g. Allow an update to cordova-ios separately from
> > cordova-blackberry10.
> >
> > Possible Advantages:
> >   - Releases will (hopefully) occur more frequently. Don't need to wait
> for
> > synchronization with other platforms to do a release.
> >
> > Possible Disadvantages:
> >   - Might make for too many releases & spam our users with release notes
> > too often
> >   - Might make us lazy and release platforms too infrequently
> >   - Might make version numbers for platforms not correspond date-wise
> with
> > version numbers of other platforms (e.g. 3.1 ios != 3.1 android)
> >
> >
> > Other considerations:
> >   cordova-js is a common piece here. Perhaps that could be pulled out as
> > well?
> >
> > Option 1: Bundle the exec bridge, platform bootstrap & plugin loader with
> > the platform, and have the rest available as a plugin.
> > Option 2: Bundle exec bridge + platform bootstrap with the platform,
> bundle
> > the plugin loader with plugman, put the rest in a plugin
> >
> > For reference, the only non-exec-bridge / start-up code I can see is:
> > ./cordova.js   <--- hooks addEventListener + has exec bridge logic
> > ./common/argscheck.js   <--- strictly a helper for plugins
> > ./common/base64.js   <--- exec bridge depends on this
> > ./common/builder.js  <--- should be folded into modulemapper.js
> > ./common/channel.js  <--- start-up code needs this
> > ./common/init.js  <--- start-up code
> > ./common/modulemapper.js  <--- start-up code
> > ./common/pluginloader.js  <--- loads plugins on start-up
> > ./common/urlutil.js   <--- recently added helper for plugins
> > ./common/utils.js   <--- mostly misc stuff that may be mostly unused?
> >
> > There's also:
> > ./windows8/windows8/commandProxy.js
> > which I assume is exec bridge releated.
> >
> > I think that argscheck & urlutil would be well-suited as stand-alone
> > plugins that other plugins depend on.
>

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