So, for tagging today, can we get the issues setup and the JS tagged at least? We can somehow muddle through this RC1.
On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux <b...@brian.io> wrote: > I'd say we could consider the core plugins as build ephemera not > unlike docs or automations. Really cordova-cli is the main point of > interaction between us and our developer community. > > > On Mon, Jul 15, 2013 at 9:03 AM, Andrew Grieve <agri...@chromium.org> wrote: >> The Apache Way was a part of what I was thinking as well. >> >> Also - it occurs to me that we'll have to change our voting system when it >> comes to plugins since each plugin repo should have a +1 from each platform >> maintainer, and can be tagged only once. >> >> >> On Fri, Jul 12, 2013 at 12:53 PM, Joe Bowser <bows...@gmail.com> wrote: >> >>> Don't we have to release a zip on an Apache server because of "The >>> Apache Way"? That's why I thought we had to release artifacts, not >>> for people, but for process. >>> >>> On Fri, Jul 12, 2013 at 9:31 AM, Brian LeRoux <b...@brian.io> wrote: >>> > I don't mind this but it seems like a lot of work to release artifacts >>> > for...who? End users we want to encourage to use the tooling golden >>> > path for creating projects, working w/ plugins, etc. >>> > >>> > If anything I'd rather we *only* distribute cordova-cli as the >>> > canonical repo and entry point for usage and treat the rest as our >>> > project build artifacts/ephemera. >>> > >>> > Way easier. Way more in tune w/ actual usage. >>> > >>> > >>> > >>> > On Fri, Jul 12, 2013 at 7:25 AM, Andrew Grieve <agri...@chromium.org> >>> wrote: >>> >> Definitely would like to get everything Release / Versioning related >>> >> documented on the wiki. The most complete source right now is: >>> >> http://wiki.apache.org/cordova/CuttingReleases We should add another >>> page >>> >> for versioning once we settle on what to do with plugins. >>> >> >>> >> Right now only CLI & Plugman are distributed on npm and are versioned >>> >> separately. Nothing else is on npm though, so package.json isn't used. >>> >> Instead VERSION files hold the version. >>> >> >>> >> I've decided I didn't like my previous proposal of not updating versions >>> >> when things don't change because it will make it harder to check out a >>> >> version of Cordova. >>> >> >>> >> New Proposal: >>> >> >>> >> 1. Each Cordova release will include: >>> >> - A copy of every repo, including all core plugins. >>> >> >>> >> 2. Each plugin repo will get a release branch even if the code hasn't >>> >> changed. >>> >> >>> >> 3. Each plugin's version will match the Cordova version >>> >> >>> >> 4. Plugins can have separate point releases if they are important >>> updates >>> >> to them. These will be in the form of tags along the release branch. >>> >> >>> >> 5. As soon as release branches are created, we change the VERSION file >>> and >>> >> re-tag master to a -dev version of the next release (e.g. 3.1.0-dev) >>> >> >>> >> >>> >> On Thu, Jul 11, 2013 at 9:05 AM, Carlos Santana <csantan...@gmail.com >>> >wrote: >>> >> >>> >>> Dumb questions >>> >>> >>> >>> Does the package.json {version:""} field needs to be updated on every >>> >>> commit to the repo? >>> >>> (meaning depending what is the commit, then the major, minor, patch, >>> or >>> >>> extension gets updated) >>> >>> Does the npm registry support pre-release and build metadata (i.e. >>> x.7.z.92 >>> >>> in 2.9.1-x.7.z.92)? >>> >>> If this true, Does npm knows to install the latest stable version, but >>> user >>> >>> can request a pre-release by specifying the version that it wants @2 >>> >>> .9.1-x.7.z.92 >>> >>> >>> >>> >>> >>> >>> >>> Refs: >>> >>> http://semver.org/ >>> >>> >>> >>> Given a version number MAJOR.MINOR.PATCH, increment the: >>> >>> >>> >>> 1. MAJOR version when you make incompatible API changes, >>> >>> 2. MINOR version when you add functionality in a >>> backwards-compatible >>> >>> manner, and >>> >>> 3. PATCH version when you make backwards-compatible bug fixes. >>> >>> >>> >>> *Additional labels for pre-release and build metadata are available as >>> >>> extensions to the MAJOR.MINOR.PATCH format.* >>> >>> >>> >>> >>> >>> On Thu, Jul 11, 2013 at 8:57 AM, Carlos Santana <csantan...@gmail.com >>> >>> >wrote: >>> >>> >>> >>> > About versioning maybe we should open a mail-thread/jira/wikipage >>> (not >>> >>> > familiar with process yet :-)) >>> >>> > To discuss and be clear what is the guideline/process to version >>> >>> different >>> >>> > components. >>> >>> > >>> >>> > Some thoughts (maybe this is already well understood and documented >>> in >>> >>> > wiki): >>> >>> > - Lets follow semantic versioning as much as possible for ALL >>> components >>> >>> > (i.e. plugins, core, cli, plugman, platform, repos) >>> >>> > - Document the deliverables/releases channels (i.e. npm, apache >>> zip/dist, >>> >>> > git repo) >>> >>> > - Maintain the versions in sync (package.json {version:""}, git tag) >>> >>> > tag/hash should match what's posted in npm registry? >>> >>> > >>> >>> > --Carlos >>> >>> > >>> >>> > >>> >>> > On Wed, Jul 10, 2013 at 7:33 PM, Andrew Grieve <agri...@chromium.org >>> >>> >wrote: >>> >>> > >>> >>> >> Coho started as just a tool to package, but has grown into a tool >>> that: >>> >>> >> a) helps work with multiple repos >>> >>> >> b) documents our release process in working code. >>> >>> >> >>> >>> >> re windows tagging - As of the last release bug template, we're >>> tagging >>> >>> >> each branch individually either via coho or not, so no issue there. >>> It >>> >>> >> won't be tagged by coho unless someone does it explicitly. I think >>> we >>> >>> can >>> >>> >> still use it to create the windows release branches, since if it >>> messes >>> >>> up >>> >>> >> we can just fix what it missed (but all it does is update VERSION >>> and >>> >>> >> cordova.js). >>> >>> >> >>> >>> >> As for plugins, I've only used CLI by pointing at directories so >>> far, >>> >>> but >>> >>> >> I >>> >>> >> was under the impression that if you give it a URL, you have to >>> give it >>> >>> a >>> >>> >> repo + subdirectory + hash/tag combination. If it's currently just >>> >>> >> installing from master, I think that's a bad default and should >>> instead >>> >>> go >>> >>> >> by a tag (npm goes by the "stable" tag by default I believe). So... >>> we >>> >>> >> will >>> >>> >> need an explicit action for commits to a plugin to be picked up by >>> >>> >> plugman. >>> >>> >> >>> >>> >> How about if a plugin has a commit that is urgent, it gets a point >>> >>> release >>> >>> >> right away. Otherwise, it waits for the next Cordova release cycle. >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On Wed, Jul 10, 2013 at 6:47 PM, Jesse <purplecabb...@gmail.com> >>> wrote: >>> >>> >> >>> >>> >> > re: COHO >>> >>> >> > I cannot guarantee the output of windows/phone releases if they >>> are >>> >>> >> tagged >>> >>> >> > and updated via coho. I like the idea of having continuous >>> >>> integration, >>> >>> >> but >>> >>> >> > this is not there yet. I would prefer for now to manually update >>> and >>> >>> >> tag >>> >>> >> > wp7+wp8+windows8 repos because I do not currently trust the magic >>> in >>> >>> >> coho, >>> >>> >> > and do not have time to go and understand all of the magic. >>> >>> >> > >>> >>> >> > @purplecabbage >>> >>> >> > risingj.com >>> >>> >> > >>> >>> >> > >>> >>> >> > On Wed, Jul 10, 2013 at 3:36 PM, Steven Gill < >>> stevengil...@gmail.com> >>> >>> >> > wrote: >>> >>> >> > >>> >>> >> > > Plugin versioning is definitely something we need to discuss in >>> >>> >> detail. >>> >>> >> > > >>> >>> >> > > What happens if I make a change to the camera plugin. Do I >>> >>> immediately >>> >>> >> > bump >>> >>> >> > > the version? Probably not. But people who install it using >>> >>> plugman/cli >>> >>> >> > > after the change will get the latest one on master with no >>> obvious >>> >>> >> > > difference to them. Version wise it is the same as before the >>> >>> change. >>> >>> >> > This >>> >>> >> > > feels wrong. >>> >>> >> > > >>> >>> >> > > We can now update plugins independently of our once a month >>> release >>> >>> >> and >>> >>> >> > get >>> >>> >> > > those updates to our users instantly. I think we should update >>> the >>> >>> >> > version >>> >>> >> > > of the plugins after every change. Similar to node-modules on >>> npm. >>> >>> >> > > >>> >>> >> > > Coho is not just for packaging. I love the fact that I can >>> clone and >>> >>> >> > update >>> >>> >> > > all of the repos in a few quick commands. Coho seems to have the >>> >>> >> ability >>> >>> >> > to >>> >>> >> > > do tagging, release packaging and signing, uploading releases to >>> >>> >> apache, >>> >>> >> > > cloning all repos and soon generating release issues on jira. It >>> >>> will >>> >>> >> be >>> >>> >> > > important to solve all of the issues people are having with >>> coho and >>> >>> >> > > document what you can do with it. >>> >>> >> > > >>> >>> >> > > >>> >>> >> > > On Wed, Jul 10, 2013 at 3:15 PM, Joe Bowser <bows...@gmail.com> >>> >>> >> wrote: >>> >>> >> > > >>> >>> >> > > > I'm going to create a new thread about this, but what's the >>> >>> purpose >>> >>> >> of >>> >>> >> > > > coho again? I thought it was just for packaging releases. >>> >>> >> > > > >>> >>> >> > > > On Wed, Jul 10, 2013 at 3:07 PM, Andrew Grieve < >>> >>> >> agri...@chromium.org> >>> >>> >> > > > wrote: >>> >>> >> > > > > Our intern Jeffrey is actively working on adding a command >>> to >>> >>> >> coho to >>> >>> >> > > be >>> >>> >> > > > > able to create release bugs (based off of cordova-labs). If >>> he >>> >>> >> gets >>> >>> >> > > done, >>> >>> >> > > > > by Monday, then it'll be a cinch to create the issues. >>> >>> >> > > > > >>> >>> >> > > > > We could maybe start by discussing what we want to do with >>> the >>> >>> >> plugin >>> >>> >> > > > repos >>> >>> >> > > > > for the release. >>> >>> >> > > > > >>> >>> >> > > > > Should they all have release branches? >>> >>> >> > > > > Should they be versioned the same? e.g. 3.0.x, or should >>> they >>> >>> >> start >>> >>> >> > out >>> >>> >> > > > at >>> >>> >> > > > > 1.0.x? >>> >>> >> > > > > Are we including a .zip of all of them in our apache >>> >>> distribution >>> >>> >> > .zip? >>> >>> >> > > > > >>> >>> >> > > > > >>> >>> >> > > > > Here's a stab at it from me: >>> >>> >> > > > > >>> >>> >> > > > > - Always include all core plugins in the apache release .zip >>> >>> >> > > > > - If a plugin has not changed since the previous release, >>> then >>> >>> >> just >>> >>> >> > put >>> >>> >> > > > in >>> >>> >> > > > > the previous release of the .zip. >>> >>> >> > > > > - E.g. for 3.1.0, if plugin-console has no changes, then >>> just >>> >>> >> > > package >>> >>> >> > > > > version 3.0.0 of the plugin in the release >>> >>> >> > > > > - Create release branches for the plugin repos only if >>> there has >>> >>> >> > been a >>> >>> >> > > > > commit since the previous release >>> >>> >> > > > > - If there were no commits, then there cannot be any >>> >>> >> regressions, >>> >>> >> > so >>> >>> >> > > > no >>> >>> >> > > > > need for a release branch. >>> >>> >> > > > > - I think they should be versioned the same to help us >>> figure >>> >>> out >>> >>> >> > when >>> >>> >> > > > the >>> >>> >> > > > > last change was. >>> >>> >> > > > > - This could mean that if plugin-console goes three >>> months >>> >>> >> > without a >>> >>> >> > > > > change, it will go from 3.0.0 straight to 3.3.0 >>> >>> >> > > > > >>> >>> >> > > > > >>> >>> >> > > > > >>> >>> >> > > > > >>> >>> >> > > > > >>> >>> >> > > > > >>> >>> >> > > > > On Wed, Jul 10, 2013 at 5:50 PM, Filip Maj <f...@adobe.com> >>> >>> wrote: >>> >>> >> > > > > >>> >>> >> > > > >> Yeah.. Maybe we should create the issues for the rc soon? >>> >>> >> > > > >> >>> >>> >> > > > >> On 7/10/13 1:57 PM, "Andrew Grieve" <agri...@chromium.org> >>> >>> >> wrote: >>> >>> >> > > > >> >>> >>> >> > > > >> >I would put that at next week unless someone has cycles >>> to get >>> >>> >> on >>> >>> >> > it >>> >>> >> > > > this >>> >>> >> > > > >> >week. >>> >>> >> > > > >> > >>> >>> >> > > > >> > >>> >>> >> > > > >> >On Wed, Jul 10, 2013 at 4:24 PM, Marcel Kinard < >>> >>> >> cmarc...@gmail.com >>> >>> >> > > >>> >>> >> > > > >> wrote: >>> >>> >> > > > >> > >>> >>> >> > > > >> >> When will the Upgrade Guides (2.9 -> 3.0) be written? >>> That >>> >>> >> > content >>> >>> >> > > is >>> >>> >> > > > >> >> currently not in cordova-docs. >>> >>> >> > > > >> >>> >>> >> > > > >> >>> >>> >> > > > >>> >>> >> > > >>> >>> >> > >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > Carlos Santana >>> >>> > <csantan...@gmail.com> >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Carlos Santana >>> >>> <csantan...@gmail.com> >>> >>> >>>
