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