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:42:12 GMT
On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mmocny@chromium.org> wrote:

>
>
>
> 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.
>>
> I still don't understand.  If the plugin had no unreleased commits, then
master version didn't increment, and dev version should remain > master
version without a bump, no?  Perhaps its supposed to say, for each plugin
that *had* a release?


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