You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2013/09/03 18:18:24 UTC
Re: Releases in a 3.0 World
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 <ic...@google.com> wrote:
> On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <ag...@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 <ag...@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 <ag...@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.
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: Releases in a 3.0 World
Posted by Ian Clelland <ic...@chromium.org>.
On Thu, Sep 5, 2013 at 5:45 AM, Plaquette, Paul <pa...@intel.com>wrote:
> hi,
>
>
> good idea.
>
> could not it create tags ? (in order to have something more readable than a
> hash)
>
I suppose it could, as long as you didn't push them until they're tested --
my reason for not suggesting that is that you may need to re-test as
problems are fixed, and once you push tags to a public repo, they should be
permanent.
I just wanted a quick way to save state locally, without changing anything
unnecessarily in the git repo itself. Just a way to say "save all of the
current hashes. Now do this to all of the repos, given these hashes that we
saved before". It shouldn't need to tag them all in order to do that.
As far as readability goes, I don't think it needs to be readable by
anything except coho itself. That said, git hashes are a pretty commonly
encountered type of string. Anyone who has worked with git should
understand what they are and how to use them, even if they are just opaque
identifiers rather than meaningful words.
Ian
> Cordially
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Paul Plaquette,
> Senior Software Engineer
> Intel Corporation SAS *
> *
> *SSG/OTC: Open Source Technology Center*
> France, Montpellier
>
>
>
> On Thu, Sep 5, 2013 at 4:32 AM, Ian Clelland <ic...@chromium.org>
> wrote:
>
> > On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > Changes should sneak into dev, not master. Unless someone else messed
> > > something up, there shouldn't be any conflicts on master.
> > >
> > > I see what you're saying though. Sneaking a change into dev while
> you're
> > > testing would mess you up a bit.
> > >
> > > One option is to push after incrementing the version and writing the
> > > changelog, that way subsequent changes will happen after your merge
> point
> > > just fine. It means that you'll have a non-dev version on master for a
> > bit,
> > > but I think that's fine. Small window.
> >
> >
> > Would this be any easier if coho had the ability to maintain, say in a
> > small text file, a list of repos and their associated hashes, as a kind
> of
> > 'snapshot'? Coho could output that format based on what it sees at a
> given
> > time, and then could use it again as input when performing certain git
> > operations.
> >
> > Something like this:
> >
> > $ coho snapshot
> > {"cordova-android": "8091a2b3c4d5e6f708192a3b4c5d6e7f",
> > "cordova-ios": "abcd1234...",
> > "cordova-plugin-camera": ...,
> > ...
> > }
> >
> > Then, you could use that to snapshot the plugin state before starting the
> > release tests, and use it when merging:
> >
> > $ coho snapshot -r plugins > CURRENT_VERSIONS
> > ... testing follows ...
> > ... ready to commit ...
> > $ coho foreach -r plugins "git checkout master"
> > $ coho foreach -r plugins --use-snapshot CURRENT_VERSIONS "git merge
> > __REVISION__ --ff-only"
> >
> > Coho would use the appropriate hash in place of __REVISION__ (or some
> other
> > placeholder) for each repo in the foreach loop.
> > ---------------------------------------------------------------------
> > Intel Corporation SAS (French simplified joint stock company)
> > Registered headquarters: "Les Montalets"- 2, rue de Paris,
> > 92196 Meudon Cedex, France
> > Registration Number: 302 456 199 R.C.S. NANTERRE
> > Capital: 4,572,000 Euros
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
>
Re: Releases in a 3.0 World
Posted by "Plaquette, Paul" <pa...@intel.com>.
hi,
good idea.
could not it create tags ? (in order to have something more readable than a
hash)
Cordially
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Plaquette,
Senior Software Engineer
Intel Corporation SAS *
*
*SSG/OTC: Open Source Technology Center*
France, Montpellier
On Thu, Sep 5, 2013 at 4:32 AM, Ian Clelland <ic...@chromium.org> wrote:
> On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Changes should sneak into dev, not master. Unless someone else messed
> > something up, there shouldn't be any conflicts on master.
> >
> > I see what you're saying though. Sneaking a change into dev while you're
> > testing would mess you up a bit.
> >
> > One option is to push after incrementing the version and writing the
> > changelog, that way subsequent changes will happen after your merge point
> > just fine. It means that you'll have a non-dev version on master for a
> bit,
> > but I think that's fine. Small window.
>
>
> Would this be any easier if coho had the ability to maintain, say in a
> small text file, a list of repos and their associated hashes, as a kind of
> 'snapshot'? Coho could output that format based on what it sees at a given
> time, and then could use it again as input when performing certain git
> operations.
>
> Something like this:
>
> $ coho snapshot
> {"cordova-android": "8091a2b3c4d5e6f708192a3b4c5d6e7f",
> "cordova-ios": "abcd1234...",
> "cordova-plugin-camera": ...,
> ...
> }
>
> Then, you could use that to snapshot the plugin state before starting the
> release tests, and use it when merging:
>
> $ coho snapshot -r plugins > CURRENT_VERSIONS
> ... testing follows ...
> ... ready to commit ...
> $ coho foreach -r plugins "git checkout master"
> $ coho foreach -r plugins --use-snapshot CURRENT_VERSIONS "git merge
> __REVISION__ --ff-only"
>
> Coho would use the appropriate hash in place of __REVISION__ (or some other
> placeholder) for each repo in the foreach loop.
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number: 302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
Re: Releases in a 3.0 World
Posted by Ian Clelland <ic...@chromium.org>.
On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve <ag...@chromium.org> wrote:
> Changes should sneak into dev, not master. Unless someone else messed
> something up, there shouldn't be any conflicts on master.
>
> I see what you're saying though. Sneaking a change into dev while you're
> testing would mess you up a bit.
>
> One option is to push after incrementing the version and writing the
> changelog, that way subsequent changes will happen after your merge point
> just fine. It means that you'll have a non-dev version on master for a bit,
> but I think that's fine. Small window.
Would this be any easier if coho had the ability to maintain, say in a
small text file, a list of repos and their associated hashes, as a kind of
'snapshot'? Coho could output that format based on what it sees at a given
time, and then could use it again as input when performing certain git
operations.
Something like this:
$ coho snapshot
{"cordova-android": "8091a2b3c4d5e6f708192a3b4c5d6e7f",
"cordova-ios": "abcd1234...",
"cordova-plugin-camera": ...,
...
}
Then, you could use that to snapshot the plugin state before starting the
release tests, and use it when merging:
$ coho snapshot -r plugins > CURRENT_VERSIONS
... testing follows ...
... ready to commit ...
$ coho foreach -r plugins "git checkout master"
$ coho foreach -r plugins --use-snapshot CURRENT_VERSIONS "git merge
__REVISION__ --ff-only"
Coho would use the appropriate hash in place of __REVISION__ (or some other
placeholder) for each repo in the foreach loop.
Re: Releases in a 3.0 World
Posted by Andrew Grieve <ag...@chromium.org>.
Changes should sneak into dev, not master. Unless someone else messed
something up, there shouldn't be any conflicts on master.
I see what you're saying though. Sneaking a change into dev while you're
testing would mess you up a bit.
One option is to push after incrementing the version and writing the
changelog, that way subsequent changes will happen after your merge point
just fine. It means that you'll have a non-dev version on master for a bit,
but I think that's fine. Small window.
On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>
>
> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@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 <ag...@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.
>> >>> > > > >> > >
>> >>> > > > >> >
>> >>> > > > >>
>> >>> > > > >
>> >>> > > > >
>> >>> > > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: Releases in a 3.0 World
Posted by Andrew Grieve <ag...@chromium.org>.
I think we should get the manual steps ironed out on the
https://wiki.apache.org/cordova/StepsForPluginRelease site before we try to
automate.
I just tried what you said and got:
> ../cordova-plugman/main.js publish .
> forbidden user: agrieve not authorized to modify
> org.apache.cordova.core.file
> Changed: dist-tags.latest "0.2.1" -> "0.1.0"
> Changed: versions.0.1.0.dist.tarball "
> http://registry.cordova.io/org.apache.cordova.core.file/-/org.apache.cordova.core.file-0.1.0.tgz"
> -> "
> http://cordova.iriscouch.com/registry/_design/scratch/_rewrite/org.apache.cordova.core.file/-/org.apache.cordova.core.file-0.1.0.tgz
> "
> Added: versions.0.1.0.directories
> Deleted: versions.0.2.1
> Changed: time.modified "2013-09-09T21:45:49.845Z" ->
> "2013-09-10T17:48:52.345Z":
> org.apache.cordova.core.file/-rev/5-20a7ea85f95935cfcd969cc1d71230fc
1. We'll need a strategy for allowing all cordova devs to have perms to
update the registry
2. It looks like even though it failed, it continued to edit the registry?
On Mon, Sep 9, 2013 at 6:57 PM, Anis KADRI <an...@gmail.com> wrote:
> 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 <mm...@chromium.org> wrote:
> > On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >
> >>
> >>
> >>
> >> On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >>
> >>>
> >>>
> >>>
> >>> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mm...@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 <ag...@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.
> >>>>> >>> > > > >> > >
> >>>>> >>> > > > >> >
> >>>>> >>> > > > >>
> >>>>> >>> > > > >
> >>>>> >>> > > > >
> >>>>> >>> > > >
> >>>>> >>> > >
> >>>>> >>> >
> >>>>> >>>
> >>>>> >>
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>
> >>
>
Re: Releases in a 3.0 World
Posted by Anis KADRI <an...@gmail.com>.
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 <mm...@chromium.org> wrote:
> On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny <mm...@chromium.org> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mm...@chromium.org> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>>>
>>>>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@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.
>>>>> >>> > > > >> > >
>>>>> >>> > > > >> >
>>>>> >>> > > > >>
>>>>> >>> > > > >
>>>>> >>> > > > >
>>>>> >>> > > >
>>>>> >>> > >
>>>>> >>> >
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
Re: Releases in a 3.0 World
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>
>
> On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mm...@chromium.org> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>>
>>>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@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.
>>>> >>> > > > >> > >
>>>> >>> > > > >> >
>>>> >>> > > > >>
>>>> >>> > > > >
>>>> >>> > > > >
>>>> >>> > > >
>>>> >>> > >
>>>> >>> >
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>
Re: Releases in a 3.0 World
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>
>
> On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>>
>>
>>
>> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <ag...@chromium.org>wrote:
>>
>>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@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?
>
>
>> >>
>>> >>
>>> >>>
>>> >>> 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.
>>> >>> > > > >> > >
>>> >>> > > > >> >
>>> >>> > > > >>
>>> >>> > > > >
>>> >>> > > > >
>>> >>> > > >
>>> >>> > >
>>> >>> >
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
Re: Releases in a 3.0 World
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>
>
> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <ag...@chromium.org>wrote:
>
>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@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 <ag...@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.
>> >>> > > > >> > >
>> >>> > > > >> >
>> >>> > > > >>
>> >>> > > > >
>> >>> > > > >
>> >>> > > >
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: Releases in a 3.0 World
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@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 <ag...@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.
> >>> > > > >> > >
> >>> > > > >> >
> >>> > > > >>
> >>> > > > >
> >>> > > > >
> >>> > > >
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Releases in a 3.0 World
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
>
>
> On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve <ag...@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 <mm...@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 <ag...@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 <ic...@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.
>>> > > > >> > >
>>> > > > >> >
>>> > > > >>
>>> > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: Releases in a 3.0 World
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve <ag...@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 <mm...@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.
>
>>
>> ======
>>
>> 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 <ag...@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 <ic...@google.com>
>> > wrote:
>> >
>> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <ag...@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.
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Releases in a 3.0 World
Posted by Andrew Grieve <ag...@chromium.org>.
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 <mm...@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.
>
> "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.
>
> ======
>
> 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 <ag...@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 <ic...@google.com>
> > wrote:
> >
> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <ag...@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 <ag...@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.
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Releases in a 3.0 World
Posted by Braden Shepherdson <br...@chromium.org>.
Tools release process looks good to me, but I've not done some parts of
that process before.
Braden
On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny <mm...@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?
> 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?
>
> ======
>
> 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?
>
> 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.
>
> "For each plugin that had unreleased commits .. increment the micro" --
> why?
>
> 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.
>
> ======
>
> 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 <ag...@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 <ic...@google.com>
> > wrote:
> >
> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <ag...@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 <ag...@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.
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Releases in a 3.0 World
Posted by Michal Mocny <mm...@chromium.org>.
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?
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?
======
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?
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.
"For each plugin that had unreleased commits .. increment the micro" --
why?
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.
======
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 <ag...@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 <ic...@google.com>
> wrote:
>
> > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <ag...@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 <ag...@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.
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>