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