cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Releases in a 3.0 World
Date Wed, 04 Sep 2013 19:18:51 GMT
On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <agrieve@chromium.org> wrote:

>
>
>
> On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve <agrieve@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 <mmocny@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.
>
>>
>>
>>>
>>> "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 <agrieve@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 <iclelland@google.com>
>>> > wrote:
>>> >
>>> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <agrieve@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 <
>>> agrieve@chromium.org>
>>> > > > wrote:
>>> > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Wed, Aug 7, 2013 at 8:49 PM, Michael Brooks <
>>> > > michael@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 <
>>> agrieve@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
<
>>> > > agrieve@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.
>>> > > > >> > >
>>> > > > >> >
>>> > > > >>
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message