cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 23:15:18 GMT
Hey Andrew,

I posted in here before reading the getting organized for 3.0 thread. I
retract my statement that every plugin needs issues and agree with plugins
being tested by platform maintainers before they tag their respective
platforms. I created one issue to tag all of the plugins once platforms are
tagged.


On Mon, Jul 15, 2013 at 4:12 PM, Joe Bowser <bowserj@gmail.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message