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 <mmo...@chromium.org> wrote: > On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve <agri...@chromium.org> wrote: > >> >> >> >> 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? >> > > 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 < >>>>> 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. >>>>> >>> > > > >> > > >>>>> >>> > > > >> > >>>>> >>> > > > >> >>>>> >>> > > > > >>>>> >>> > > > > >>>>> >>> > > > >>>>> >>> > > >>>>> >>> > >>>>> >>> >>>>> >> >>>>> >> >>>>> > >>>>> >>>> >>>> >>> >>
