cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 18:56:51 GMT
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>
>>> >>>
>>>

Mime
View raw message