On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny <mmo...@chromium.org> wrote:
> > > > On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny <mmo...@chromium.org> wrote: > >> >> >> >> On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve <agri...@chromium.org>wrote: >> >>> On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve <agri...@chromium.org> >>> wrote: >>> >>> > >>> > >>> > >>> > On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve <agri...@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 <mmo...@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 <agri...@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 < >>> iclell...@google.com> >>> >>> > wrote: >>> >>> > >>> >>> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve < >>> agri...@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 < >>> >>> agri...@chromium.org> >>> >>> > > > wrote: >>> >>> > > > >>> >>> > > > > >>> >>> > > > > >>> >>> > > > > >>> >>> > > > > On Wed, Aug 7, 2013 at 8:49 PM, Michael Brooks < >>> >>> > > mich...@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 < >>> >>> agri...@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 < >>> >>> > > agri...@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. >>> >>> > > > >> > > >>> >>> > > > >> > >>> >>> > > > >> >>> >>> > > > > >>> >>> > > > > >>> >>> > > > >>> >>> > > >>> >>> > >>> >>> >>> >> >>> >> >>> > >>> >> >> >
