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.er...@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 <agri...@chromium.org> > wrote: > > > Gorkem, could you elaborate? > > > > > > On Tue, Aug 6, 2013 at 7:22 PM, Gorkem Ercan <gorkem.er...@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 <agri...@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. > > > > > > > > > >
