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. > > > > > >
