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> >>>> >>> >>>>
