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 23:12:29 GMT
So, since we're stuck with coho if we want to get this done this week,
how do you get coho to check out a branch of all the plugins?

On Mon, Jul 15, 2013 at 4:10 PM, Andrew Grieve <agrieve@chromium.org> wrote:
> On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill <stevengill97@gmail.com> wrote:
>
>> We will need to add issues for tagging plugins.
>
> What's your reasoning?
>
>
>
>> I can create the issue and
>> tag the plugins. I figure for now, plugins will use same tagging process as
>> other repos.
>>
> And that process is?
>
> For the RC - it's trivial to create release branches and an RC tag. coho
> can do it in bulk. The main question is what criteria should we use to
> determine whether a plugin is ready for tagging? For an RC, we could just
> tag with whatever's there , but then it's not really adding any meaning on
> top of the release branch existing. I think the thing that separates the
> release branch from the tag is some testing.
>
>
>>
>>
>> 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>
>> > >>>> >>>
>> > >>>>
>> >
>> >
>>

Mime
View raw message