> > 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 only advocate semver for node modules and you can expect that I'll be pushing this on cordova-cli soon. :) Node modules use semver. Regardless of whether it's effective or not, it's what the community uses and as developers we should attempt to respect and adhere to it. However, Cordova uses a different type of versioning scheme. The CLI tool needs to represent both of these versioning schemes. - The Cordova version is most important, because it describe what version of Cordova the CLI uses. - The node module version is important to modules consuming cordova-cli. You have no idea how frustrating cordova-cli's current versioning is wrt to the phonegap-cli. This is why a version such as 3.0.0-0.10.4 works extremely well. It's distributing version 3.0.0 of Cordova. The node module itself is version 0.10.4. It's also semantically valid in semver, so it's compatible with npm. Michael On Wed, Aug 7, 2013 at 1:27 PM, Andrew Grieve <agri...@chromium.org> wrote: > 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. > > >
