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