Changes should sneak into dev, not master. Unless someone else messed something up, there shouldn't be any conflicts on master.
I see what you're saying though. Sneaking a change into dev while you're testing would mess you up a bit. One option is to push after incrementing the version and writing the changelog, that way subsequent changes will happen after your merge point just fine. It means that you'll have a non-dev version on master for a bit, but I think that's fine. Small window. On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mmo...@chromium.org> wrote: > > > > On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <agri...@chromium.org>wrote: > >> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <agri...@chromium.org> >> wrote: >> >> > >> > >> > >> > On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve <agri...@chromium.org >> >wrote: >> > >> >> Responses inline. For all of them, I'll update the wiki to make things >> >> clear. >> >> >> >> >> >> On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny <mmo...@chromium.org >> >wrote: >> >> >> >>> For Strategy page: >> >>> >> >>> RE: Weekly Releases -- do we skip a release if there is nothing >> >>> significant >> >>> to push, or do we release so long as there is at least one patch? >> >>> >> >> I'd say skip. >> >> >> >> >> >> >> >>> RE: Cadence Releases -- "These releases include: platform repos, >> >>> cordova-js, mobile-spec, cordova-docs, cordova-cli, cordova-plugman" >> -- >> >>> clarifying that "include" for the sem-ver projects means only >> packaging >> >>> into a zip/tarball, not that we bump versions numbers during a cadence >> >>> release? Or do we bump sem-ver as well? >> >>> >> >> >> >> cordova-js, mobile-spec, cordova-docs, cordova-cli: Update their >> versions >> >> to the current CadVer >> >> plugman: Probably should be removed from this list. >> >> platform-repos: semver bump if there were any changes since prev >> release. >> >> >> >> >> >> >> >>> ====== >> >>> >> >>> For plugin release page: >> >>> "# Edit version within plugin.xml based off of changes." --- this >> >>> means >> >>> "deduce the semantic effect on version" right? IE, is it a >> >>> major/minor/point release? >> >>> >> >> Yes (will update wording) >> >> >> >>> >> >>> Generally, how do we prevent changes from sneaking in to core plugins >> >>> during the time it takes release master to make the changes? The >> release >> >>> master has to commit back to Changelog. Perhaps he/she makes that >> change >> >>> directly on master, and we rebase that change back into dev after the >> >>> release? That way, we don't read from dev branch once a release >> process >> >>> is >> >>> started. >> >>> >> >> Hrm, how about instead of merging dev->master, we merge CHANGELOG.md >> >> commit -> master. >> >> >> > Actually, this will work fine as-is so long as you don't git pull in the >> > middle of things. going to leave as-is. >> > > You'll need to pull again in order to push if a commit snuck in, no? > > The steps right now seem to be: pull dev, Update Changelog and VERSION, > push to dev. Which may perhaps be automated into such a small window that > it doesn't matter, but if it includes reviewing each change and testing, > then it may mean opportunity for new changes to sneak into master. > > >> > >> >> >> >> >> >>> >> >>> "For each plugin that had unreleased commits .. increment the micro" >> -- >> >>> why? >> >>> >> >> So that the version on dev is greater than the version on master. >> >> >> >> >> >>> >> >>> TEST section -- suggest adding a not to the top of the guide so that >> you >> >>> create mobile-spec BEFORE starting the release. This way, you create >> a >> >>> project with the old versions of plugins more easily. >> >>> >> >> >> >> Good idea. >> >> >> > Actually - going to wait on this as well. It's unlikely that even before >> you start that you'll have the old versions of things checked out (more >> likely you have some in-between releases state). Once we have the >> registry, >> we can do this easily. >> >> >> > >> >>> ====== >> >>> >> >>> Generally these looks really good (haven't finished reading Cadence >> >>> release >> >>> doc yet, will comment on that soon). However, while I love the code >> >>> snippets for suggested commands, some of them look like they wouldn't >> >>> work >> >>> if you copy&paste them. Perhaps we should go through the docs on the >> >>> next >> >>> release and make it clear which are verbatim commands and which are >> just >> >>> documentation-with-code. >> >>> >> >>> >> >>> >> >>> >> >>> On Tue, Sep 3, 2013 at 12:18 PM, Andrew Grieve <agri...@chromium.org> >> >>> wrote: >> >>> >> >>> > Finally finished updating the wiki's instructions to follow this >> >>> proposal. >> >>> > >> >>> > Summary of changes: >> >>> > >> >>> > https://wiki.apache.org/cordova/VersioningAndReleaseStrategy >> >>> > - Explains our versioning strategy (SemVer vs CadVer) >> >>> > >> >>> > https://wiki.apache.org/cordova/CommitterWorkflow >> >>> > - Extracted Pull Requst Processing into its own page ( >> >>> > ProcessingPullRequests< >> >>> > https://wiki.apache.org/cordova/ProcessingPullRequests> >> >>> > ) >> >>> > - Added a "Which Branch to Commit To" section >> >>> > - Minor tweaks to commit process: >> >>> > - Mention `git rebase origin/master -i` >> >>> > - Marked some steps as optional >> >>> > - Linked to post-review (rbtools) install page >> >>> > - Made it more explicit that you should test commits you patch >> in >> >>> > >> >>> > https://wiki.apache.org/cordova/StepsForPluginRelease >> >>> > - Process to go through to update core plugins >> >>> > >> >>> > https://wiki.apache.org/cordova/StepsForToolsRelease >> >>> > - Process to go through to update plugman / CLI >> >>> > >> >>> > https://wiki.apache.org/cordova/CuttingReleases >> >>> > - Made it clear that it applies to Cadence Releases >> >>> > - Expanded "What to test" section >> >>> > - Added releasing of CLI to the steps >> >>> > - Moved "Official Apache Releases" to the bottom >> >>> > >> >>> > To all steps release steps pages, I've added an "Update >> CHANGELOG.md" >> >>> step. >> >>> > iOS has done this forever, but I think all repos should do it. >> >>> > >> >>> > Would love if these pages could be read by all committers. >> Especially >> >>> the >> >>> > StepsForToolsRelease page, as I've never done a tools release (and >> so >> >>> was >> >>> > somewhat guessing). >> >>> > >> >>> > Another part I'm unsure of is where the mapping to platform repo >> >>> versions >> >>> > is within CLI. >> >>> > >> >>> > There are still some points to discuss, which I will send separate >> >>> emails >> >>> > about :) >> >>> > >> >>> > >> >>> > On Sun, Aug 18, 2013 at 11:30 PM, Ian Clelland < >> iclell...@google.com> >> >>> > wrote: >> >>> > >> >>> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve < >> agri...@chromium.org >> >>> > >> >>> > > wrote: >> >>> > > >> >>> > > > After the discussion on the group hangout + some sleeping, I >> think >> >>> > we're >> >>> > > > ready for a proposal... So here it is! >> >>> > > > - It does *not* propose any changes to our Deprecation policy. >> >>> That's >> >>> > for >> >>> > > > another thread (which I'll get to on Monday if no one else >> does) :) >> >>> > > > - It does not contain how we store version numbers. That's >> covered >> >>> > here: >> >>> > > > http://wiki.apache.org/cordova/StoringRepoVersionsDesign >> >>> > > > >> >>> > > > Once we get to a consensus, I'll transfer this to the wiki. >> Please >> >>> > > review & >> >>> > > > comment! >> >>> > > > >> >>> > > > There are two kinds of versions: >> >>> > > > 1. "SemVer" (www.semver.org) >> >>> > > > - Used by platforms, plugman, cli >> >>> > > > 2. "CadVer" (just made that up :P "Cadence Version") >> >>> > > > - Used by cli, mobile-spec, cordova-js >> >>> > > > >> >>> > > > >> >>> > > I like this, as it separates the fast-moving, feature-based >> semantic >> >>> > > version of any given component from the API level, and >> >>> interoperability >> >>> > > promises, of the "Cadence Version". >> >>> > > >> >>> > > What, then, is the granularity of the Cadence Version intended to >> >>> be? Is >> >>> > is >> >>> > > the "3" in Cordova 3.0, and will stay at 3 until it hits 4 next >> year? >> >>> > (Or, >> >>> > > just as descriptively, we can say that it is at "Cordova >> Fancy-Pants" >> >>> > now, >> >>> > > and eventually progress to "Cordova Enraged-Wombat") >> >>> > > >> >>> > > Or is it going to have major and minor components as well, and >> >>> advance >> >>> > > roughly monthly, as before? >> >>> > > >> >>> > > >> >>> > > > There are two kinds of releases: >> >>> > > > 1. Patch releases >> >>> > > > - Pretty much any repo can release a patch release to fix >> bugs >> >>> at >> >>> > any >> >>> > > > time (but should have good reason) >> >>> > > > 2. Cadence releases >> >>> > > > - These follow the 10 releases per year, as enumerated on: >> >>> > > > http://wiki.apache.org/cordova/RoadmapProjects >> >>> > > > >> >>> > > > cordova-plugins: >> >>> > > > - Commit only to the `dev` branch >> >>> > > > - Use semver for them. >> >>> > > > - If the version on master is "3.0.0", then the version on >> dev >> >>> will >> >>> > > > start at "3.0.1-dev". >> >>> > > > - If any commit goes in that add a feature, then change the >> >>> version >> >>> > on >> >>> > > > dev to "3.1.0-dev" >> >>> > > > - If any commit goes in that makes an >> non-backwards-compatible >> >>> > change, >> >>> > > > then change the version on dev to "4.0.0-dev" >> >>> > > > - Release plugins at most once a week (Thursdays?) >> >>> > > > - This *does* mean that a change that goes in Wednesday could >> >>> end up >> >>> > > > being released the next day. >> >>> > > > - Release plugins all at the same time so that we can blog the >> >>> release >> >>> > > > notes. >> >>> > > > - Release process: >> >>> > > > 1. Create a JIRA issue to track the status of the release. >> >>> > > > a. Comments should be added to this bug after each >> top-level >> >>> step >> >>> > > > below is taken >> >>> > > > 2. For each plugin that has unreleased commits on their `dev` >> >>> > branch: >> >>> > > > a. Update its CHANGELOG file with a prettified version of >> "git >> >>> > log" >> >>> > > > b. Update its plugin.xml version by removing the "-dev" >> suffix >> >>> > > > c. Merge dev -> master (without pushing) >> >>> > > > d. Update its plugin.xml version by incrementing the micro >> and >> >>> > > adding >> >>> > > > "-dev" (as described above) >> >>> > > > 3. Combine all plugin changelogs into a Release announcement >> >>> blog >> >>> > post >> >>> > > > on cordova-website. >> >>> > > > a. Steps for this exist in cordova-website's README.md >> >>> > > > 4. Test >> >>> > > > a. Create mobilespec using the old versions of plugins >> >>> > > > b. Perform a "plugin upgrade" for plugins that have changes >> >>> (right >> >>> > > > now, this means doing a `plugin remove` followed by a `plugin >> add` >> >>> > > > c. Run through mobilespec, ensuring to do manual tests that >> >>> relate >> >>> > > to >> >>> > > > changes in the changelog >> >>> > > > 5. Push! >> >>> > > > a. Push all branches >> >>> > > > b. Push the blog post >> >>> > > > >> >>> > > > cordova-plugman: >> >>> > > > - Commit to master always >> >>> > > > - Release only when necessary. >> >>> > > > - Release process: >> >>> > > > 1. For releases that increment the minor or major, email the >> >>> dev >> >>> > list >> >>> > > > to let others know about your intent to release (include >> changelog) >> >>> > > > a) Wait for at least one +1 >> >>> > > > 2. Increment the version within package.json >> >>> > > > 3. Update RELEASENOTES.md with the changes for this release >> >>> > > > 4. Push to npmjs.org >> >>> > > > * In order to push, you must be given push access to the >> npm >> >>> > > module. >> >>> > > > * To do so, ask one of the existing module maintainers >> >>> (listed >> >>> > > here: >> >>> > > > https://npmjs.org/package/plugman) >> >>> > > > 5. Post a release announcement on the cordova blog (for >> feature >> >>> > > > releases only) >> >>> > > > a. Steps for this exist in cordova-website's README.md >> >>> > > > b. Not necessary for patch releases, but feature releases >> >>> should >> >>> > > > mention significant bugs fixed by previous patch releases. >> >>> > > > >> >>> > > > No JIRA: The process is light-weight enough that a JIRA issue >> isn't >> >>> > > > necessary for tracking. >> >>> > > > >> >>> > > > >> >>> > > > cordova-cli: >> >>> > > > - Commit to master, release from release branches (2.9.x, >> 3.0.x, >> >>> etc) >> >>> > > > - Versioned using "$COROVA_VERSION-$CLI_VERSION" >> >>> > > > - E.g. 3.0.0-0.5.1 >> >>> > > > - The first version component is the "cadence version", and >> >>> has its >> >>> > > > minor incremented whenever the platform repository that it lazy >> >>> loads >> >>> > by >> >>> > > > default is changed >> >>> > > > - E.g. 3.0.0 uses cordova-blackberry@3.0.0, >> >>> cordova-ios@3.0.0, >> >>> > > > cordova-android@3.0.0 >> >>> > > > - E.g. 3.1.0 uses cordova-blackberry@3.1.0, >> >>> cordova-ios@3.0.1, >> >>> > > > cordova-android@4.0.0 >> >>> > > > - E.g. 3.2.0 uses cordova-blackberry@3.1.1, >> >>> cordova-ios@3.1.0, >> >>> > > > cordova-android@4.0.1 >> >>> > > > - E.g. 3.2.1 uses cordova-blackberry@3.1.2, >> >>> cordova-ios@3.1.0, >> >>> > > > cordova-android@4.0.1 >> >>> > > > - The version number of cordova-cli will be the version number >> >>> that >> >>> > we >> >>> > > > advertise on our website, blogs & docs >> >>> > > > - Platform version numbers will use semver, and not be >> >>> > referenced >> >>> > > > - Release process for patch releases: >> >>> > > > 1. cherry-pick commits from master -> latest release branch >> >>> > > > 2. Increment package.json's micro version >> >>> > > > 3. Update RELEASENOTES.md >> >>> > > > 4. Push to npmjs.org >> >>> > > > * In order to push, you must be given push access to the >> npm >> >>> > > module. >> >>> > > > * To do so, ask one of the existing module maintainers >> >>> (listed >> >>> > > here: >> >>> > > > https://npmjs.org/package/cordova) >> >>> > > > - Release process for minor version >> >>> > > > - Same as patch release, and in addition: >> >>> > > > 1. Email the dev list to let others know about your >> intent to >> >>> > > release >> >>> > > > (include changelog) >> >>> > > > a. Wait for at least one +1 >> >>> > > > 2. Post a release announcement on the cordova blog (for >> >>> feature >> >>> > > > releases only) >> >>> > > > a. Steps for this exist in cordova-website's README.md >> >>> > > > b. Not necessary for patch releases, but feature >> releases >> >>> > should >> >>> > > > mention significant bugs fixed by previous patch releases. >> >>> > > > - Release process for major version: >> >>> > > > - Refer to platform release process. >> >>> > > > >> >>> > > > cordova platforms, mobile-spec, cordova-js: >> >>> > > > - Same as before (as documented on >> >>> > > > http://wiki.apache.org/cordova/CuttingReleases) >> >>> > > > - Except: >> >>> > > > - Platforms versions to use semver. This *does* mean that >> they >> >>> will >> >>> > > > diverge from each other. >> >>> > > > - cordova-js and cordova-mobile-spec to use the "cadence >> >>> version" >> >>> > > > (first part of cordova-cli's version) >> >>> > > > - No longer update cordova-app-template >> >>> > > > - Blog post will include changelog for all changes since >> >>> previous >> >>> > > > platforms release. >> >>> > > > - JIRA issue should have a comment that lists the platform >> >>> versions >> >>> > > > that are referenced by the cadence version. >> >>> > > > >> >>> > > > JIRA workflow: >> >>> > > > - When issues are closed, the "fixed version" should be set to >> >>> the >> >>> > > > cadence version. >> >>> > > > >> >>> > > > >> >>> > > > Andrew >> >>> > > > >> >>> > > > >> >>> > > > On Thu, Aug 8, 2013 at 4:18 PM, Andrew Grieve < >> >>> agri...@chromium.org> >> >>> > > > wrote: >> >>> > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > On Wed, Aug 7, 2013 at 8:49 PM, Michael Brooks < >> >>> > > mich...@michaelbrooks.ca >> >>> > > > >wrote: >> >>> > > > > >> >>> > > > >> > >> >>> > > > >> > Plugins and CLI tools I think we should just ship >> >>> continuously. >> >>> > The >> >>> > > > >> >> >>> > > > > Why do you think these should be shipped continuously instead >> of >> >>> on a >> >>> > > > > regular cadence? Note that I think they should be as well, but >> >>> I'm >> >>> > > trying >> >>> > > > > to figure out why the tools & plugins are different from the >> >>> > platforms. >> >>> > > > > >> >>> > > > > >> >>> > > > >> > 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. >> >>> > > > >> >> >>> > > > > I agree that keeping the number of different version numbers >> to a >> >>> > > minimum >> >>> > > > > makes things easier to track. >> >>> > > > > I don't really follow your logic about IDEs and SDKs... This >> >>> would be >> >>> > > an >> >>> > > > > argument to *not* synchronize releases I think, since >> >>> > iOS/Android/WP/BB >> >>> > > > do >> >>> > > > > not synchronize their SDK releases :P >> >>> > > > > I don't think we can apply the cadence argument to platforms, >> >>> but not >> >>> > > to >> >>> > > > > tools & plugins. Why would platforms be different in this >> >>> respect? >> >>> > > > > >> >>> > > > > > > >> >>> > > > >> > > 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. >> >>> > > > >> >> >>> > > > > With the latest <engine> tag work being done ( >> >>> > > > > https://issues.apache.org/jira/browse/CB-4490), platforms as >> >>> well as >> >>> > > > > plugins will be checked using semver. These checks will likely >> >>> work >> >>> > > > better >> >>> > > > > if we try and follow semver. AFAICT, we mostly do already >> follow >> >>> it, >> >>> > > with >> >>> > > > > the exception of our deprecation policy. >> >>> > > > > >> >>> > > > > >> >>> > > > >> > > >> >>> > > > >> > > (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. >> >>> > > > >> > > >> >>> > > > >> > >> >>> > > > >> >> >>> > > > > >> >>> > > > > >> >>> > > > >> >>> > > >> >>> > >> >>> >> >> >> >> >> > >> > >
