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 Thu, 08 Aug 2013 20:09:47 GMT
The way we release things right now, we don't ensure feature parity across
platforms for releases. The release numbers map strictly to points in time,
so we're already in a world where choosing "3.5" will leave you with
different feature sets across platforms. We could certainly consider
changing to feature-based releases, but just wanted to point out that it's
not our historic flow.


On Wed, Aug 7, 2013 at 3:42 PM, Gorkem Ercan <gorkem.ercan@gmail.com> wrote:

> Synchronized versions, releases provides a guidance for what
> features/fixes/bugs to be expected at least on the main platforms. Let's
> assume that both distro A and distro B are based on Cordova (core) 3.5 but
> because they have to choose a platform version on top of the core  for each
> platform. It will be now easily possible that we end up with the new iFart
> feature to be available on Android but no other platforms on Distro A while
> Distro B gets it for all platforms but wp8.
>
> I know that distros are not the responsibility of this project and it is
> possible for a distro to fall into the same situation today. However, today
> we do provide a version and guidance that tells everyone cordova version
> X.X should be. I am afraid that if all parts of cordova can release
> independently that will blur.
> --
> Gorkem
>
>
> On Wed, Aug 7, 2013 at 10:32 AM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Gorkem, could you elaborate?
> >
> >
> > On Tue, Aug 6, 2013 at 7:22 PM, Gorkem Ercan <gorkem.ercan@gmail.com>
> > wrote:
> >
> > > Another disadvantage is,  this may cause downstream distributions of
> > > Cordova to get fragmented.
> > > --
> > > Gorkem
> > >
> > >
> > >
> > > On Tue, Aug 6, 2013 at 4: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