cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 16:48:13 GMT
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