cordova-dev mailing list archives

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

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

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