So, since we're stuck with coho if we want to get this done this week, how do you get coho to check out a branch of all the plugins?
On Mon, Jul 15, 2013 at 4:10 PM, Andrew Grieve <agri...@chromium.org> wrote: > On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill <stevengil...@gmail.com> wrote: > >> We will need to add issues for tagging plugins. > > What's your reasoning? > > > >> I can create the issue and >> tag the plugins. I figure for now, plugins will use same tagging process as >> other repos. >> > And that process is? > > For the RC - it's trivial to create release branches and an RC tag. coho > can do it in bulk. The main question is what criteria should we use to > determine whether a plugin is ready for tagging? For an RC, we could just > tag with whatever's there , but then it's not really adding any meaning on > top of the release branch existing. I think the thing that separates the > release branch from the tag is some testing. > > >> >> >> On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj <f...@adobe.com> wrote: >> >> > Created the issues: https://issues.apache.org/jira/browse/CB-4208 >> > >> > On 7/15/13 11:56 AM, "Joe Bowser" <bows...@gmail.com> wrote: >> > >> > >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> >> > >>>> >>> >> > >>>> >> > >> > >>
