cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Releases in a 3.0 World
Date Mon, 09 Sep 2013 22:57:35 GMT
Reviving this thread for 3.1

One thing that is not part of [1] is publishing all plugins and
updating versions to our registry.

Could coho automate this process as well ?

Basically we need to run "plugman publish cordova-plugin-*" after
updating each plugin version.

[1] http://wiki.apache.org/cordova/CuttingReleases

On Thu, Sep 5, 2013 at 9:21 AM, Michal Mocny <mmocny@chromium.org> wrote:
> On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve <agrieve@chromium.org> wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny <mmocny@chromium.org> wrote:
>>
>>>
>>>
>>>
>>> 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?
>>>
>> Sounds right to me. "had unreleased commits" == "had a release", no?
>>
>
> Okay thats my confusion.  A plugin may have commits which we decide are not
> important enough to warrant releasing (you clarified that earlier).  So
> "had unreleased commits" to me meant "all plugins whose commits on dev are
> not being released to master at this moment".  May want to clarify the
> wiki, but at least we are on the same page.
>
>
>>
>>
>>>
>>>
>>>>  >>
>>>>> >>
>>>>> >>>
>>>>> >>> 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
View raw message