Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of stevengill97@gmail.com
 designates 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CE09954A.2265F%fil@adobe.com>
References: 
 <CAOBL_k7jC2V1ecM2RurTQThX=DZn5Fi4xAc7Syo-SwBNasTpXA@mail.gmail.com>
 <CE09954A.2265F%fil@adobe.com>
From: Steven Gill <stevengill97@gmail.com>
Date: Mon, 15 Jul 2013 14:22:39 -0700
Message-ID: 
 <CAMSbhBhHtzwC=oDD1+dxvdYFd16sUsSQjYr_tYBe8+Ok1-zVSQ@mail.gmail.com>
Subject: Re: tag 3.0.0rc1 on Monday the 15th
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=089e0117683f03989504e193779b

--089e0117683f03989504e193779b
Content-Type: text/plain; charset=ISO-8859-1

We will need to add issues for tagging plugins. I can create the issue and
tag the plugins. I figure for now, plugins will use same tagging process as
other repos.


On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj <fil@adobe.com> wrote:

> Created the issues: https://issues.apache.org/jira/browse/CB-4208
>
> On 7/15/13 11:56 AM, "Joe Bowser" <bowserj@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 <agrieve@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 <bowserj@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
> >>>><agrieve@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
> >>>><csantana23@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
> >>>><csantana23@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
> >>>><agrieve@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
> >>>><purplecabbage@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 <
> >>>> stevengill97@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
> >>>><bowserj@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 <
> >>>> >>> >> agrieve@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
> >>>><fil@adobe.com>
> >>>> >>> wrote:
> >>>> >>> >> > > > >
> >>>> >>> >> > > > >> Yeah.. Maybe we should create the issues for the rc
> >>>>soon?
> >>>> >>> >> > > > >>
> >>>> >>> >> > > > >> On 7/10/13 1:57 PM, "Andrew Grieve"
> >>>><agrieve@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 <
> >>>> >>> >> cmarcelk@gmail.com
> >>>> >>> >> > >
> >>>> >>> >> > > > >> wrote:
> >>>> >>> >> > > > >> >
> >>>> >>> >> > > > >> >> When will the Upgrade Guides (2.9 -> 3.0) be
> >>>>written?
> >>>> That
> >>>> >>> >> > content
> >>>> >>> >> > > is
> >>>> >>> >> > > > >> >> currently not in cordova-docs.
> >>>> >>> >> > > > >>
> >>>> >>> >> > > > >>
> >>>> >>> >> > > >
> >>>> >>> >> > >
> >>>> >>> >> >
> >>>> >>> >>
> >>>> >>> >
> >>>> >>> >
> >>>> >>> >
> >>>> >>> > --
> >>>> >>> > Carlos Santana
> >>>> >>> > <csantana23@gmail.com>
> >>>> >>> >
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>> --
> >>>> >>> Carlos Santana
> >>>> >>> <csantana23@gmail.com>
> >>>> >>>
> >>>>
>
>

--089e0117683f03989504e193779b--