cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [DISCUSS] Plugin master branches
Date Fri, 25 Apr 2014 15:42:11 GMT
I've created https://issues.apache.org/jira/browse/CB-6521 to track this
now.

My plan is to merge all of the dev branches into master, and push that. At
that point, anyone pushing new changes can just push directly to master,
and everything should be good.

If I delete the dev branches immediately after doing that (really just the
branch name, at that point), is that going to interfere with anyone's
workflow? I hope that anyone with outstanding changes on a dev branch can
just rebase them onto master after a git pull.

Alternately, I can make a commit onto the dev branches that removes all of
the code and replaces it with a "Development has moved to master" readme
file. That should cause a good merge conflict for anyone trying to commit
to dev after that point, and will stop people from accidentally recreating
the dev branch when they go to push.


On Thu, Apr 24, 2014 at 4:11 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> A good reference would be:
>
> https://github.com/apache/cordova-coho/blob/master/docs/committer-workflow.md
>
> On Thu, Apr 24, 2014 at 1:58 PM, Piotr Zalewa <pzalewa@mozilla.com> wrote:
> > I think we should have a sane contributing to Cordova page which would
> > explain which branch does what.
> >
> > I agree master is a default for a bleeding edge with tags representing
> > current release.
> >
> > Dnia Thu Apr 24 11:56:45 2014 Braden Shepherdson pisze:
> >
> >> Standardizing the release tag names so that it can find the "latest" one
> >> is
> >> a can of worms I don't want us to open.
> >>
> >> The normal, standard flow is to install from the registry. If you're
> using
> >> the nonstandard git way, it's your job to pick the right branch, and
> >> master
> >> is the correct default. Choosing any other tag is much more surprising
> >> than
> >> using master when you're pulling from git with a bare URL.
> >>
> >> Users can already do "
> >> https://github.com/apache/cordova-plugin-inappbrowser#commitish" (or
> >> #:sub/dir, or #commitish:sub/dir). We support naming whatever branch,
> tag,
> >> or commit hash you like if you need something specific. master is the
> sane
> >> default.
> >>
> >> Braden
> >>
> >>
> >> On Wed, Apr 23, 2014 at 10:36 AM, purplecabbage
> >> <purplecabbage@gmail.com>wrote:
> >>
> >>>
> >>>> On Apr 23, 2014, at 7:16 AM, Carlos Santana <csantana23@gmail.com>
> >>>
> >>> wrote:
> >>>>
> >>>>
> >>>> +1 on using one branch "master"
> >>>>
> >>>> But, should we look into changing/enhancing the default behavior for
> >>>
> >>> "git"
> >>>>
> >>>> plugin install implementation to:
> >>>>
> >>>> if just a git url "
> https://github.com/apache/cordova-plugin-inappbrowser
> >>>
> >>> "
> >>>>
> >>>> it will query the tags/releases, and not pull latest commit and
> instead
> >>>> pull down latest release "r.0.4.0" from master.
> >>>>
> >>>> Or it's not worth? user can just do "
> >>>> https://github.com/apache/cordova-plugin-inappbrowser@r.0.4.0"
> >>>
> >>>
> >>> Yes, this.
> >>>
> >>>>
> >>>> --Carlos
> >>>>
> >>>>
> >>>>
> >>>>> On Wed, Apr 23, 2014 at 9:30 AM, Michal Mocny <mmocny@chromium.org>
> >>>
> >>> wrote:
> >>>>>
> >>>>>
> >>>>> Also, it will only "break" new plugin installs.
> >>>>>
> >>>>>
> >>>>> On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland <
> iclelland@chromium.org
> >>>>>>
> >>>>>> wrote:
> >>>>>
> >>>>>
> >>>>>> To be clear, this is just referring to Cordova CLI versions
3.0.0 -
> >>>>>
> >>>>> 3.0.4,
> >>>>>>
> >>>>>> I think. By version 3.0.5, CLI had a dependency on plugman 0.10.0,
> >>>
> >>> which
> >>>>>>
> >>>>>> included the "plugman-registry" branch. (We didn't push anything
to
> >>>>>> the
> >>>>>> registry until 3.1 was released, but we made sure that the
> >>>
> >>> infrastructure
> >>>>>>
> >>>>>> was ready a while before).
> >>>>>>
> >>>>>> If it is possible to use later versions of cordova-cli on a
project
> >>>
> >>> that
> >>>>>>
> >>>>>> uses Cordova 3.0 engines, then we should be clear that we're
not
> >>>
> >>> breaking
> >>>>>>
> >>>>>> Cordova 3.0 projects; just the oldest versions of the CLI, which
> >>>>>
> >>>>> developers
> >>>>>>
> >>>>>> should be encouraged to upgrade in any case.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Apr 22, 2014 at 9:00 PM, Andrew Grieve <
> agrieve@chromium.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Didn't know about npm deprecate. Makes sense to me!
> >>>>>>>
> >>>>>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <shazron@gmail.com>
> wrote:
> >>>>>>>> Can we deprecate version 3.0?
> >>>>>>>> https://www.npmjs.org/doc/cli/npm-deprecate.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Tue, Apr 22, 2014 at 4:00 PM, Anis KADRI <
> anis.kadri@gmail.com>
> >>>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> +1 as well. This will break Cordova 3.0 though.
Cordova versions
> >=
> >>>>>>
> >>>>>> 3.1
> >>>>>>>
> >>>>>>> are
> >>>>>>>>>
> >>>>>>>>> fine because they support registries. Cordova 3.0
only supports
> git
> >>>>>>
> >>>>>> and
> >>>>>>>
> >>>>>>> can
> >>>>>>>>>
> >>>>>>>>> only fetch from master branches.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Tue, Apr 22, 2014 at 11:32 AM, Joe Bowser <bowserj@gmail.com>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <shazron@gmail.com>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> +1++
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Apr 22, 2014 at 10:55 AM, Steven
Gill <
> >>>>>>>
> >>>>>>> stevengill97@gmail.com
> >>>>>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> +1!
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Apr 22, 2014 at 10:02 AM, James
Jong <
> >>>>>>
> >>>>>> wjamesjong@gmail.com
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> +1 Making it easier and less confusing
for our new
> >>>>>
> >>>>> contributors
> >>>>>>>
> >>>>>>> is
> >>>>>>>>>>
> >>>>>>>>>> good.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -James Jong
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Apr 22, 2014, at 12:07 PM, Andrew
Grieve <
> >>>>>>>
> >>>>>>> agrieve@chromium.org>
> >>>>>>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> +1! Certainly it's causing us
a lot of pain still. Moving
> >>>>>
> >>>>> to
> >>>>>>>>>>
> >>>>>>>>>> releasing
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> off
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> of master seems like it would
work fine. It's been working
> >>>>>>
> >>>>>> fine
> >>>>>>>>>
> >>>>>>>>> for
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> CLI/plugman, and they move much
faster.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Apr 22, 2014 at 11:37
AM, Braden Shepherdson <
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> braden@chromium.org>wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We originally needed the
plugin releases to be on the
> >>>>>
> >>>>> master
> >>>>>>>>>
> >>>>>>>>> branch
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> there was no way to have
CLI/Plugman fetch from other
> >>>>>>>
> >>>>>>> branches.
> >>>>>>>>>>
> >>>>>>>>>> That
> >>>>>>>>>>>>
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> no
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> longer the case. Further,
you're correct that the
> >>>>>
> >>>>> registry's
> >>>>>>>>>>
> >>>>>>>>>> tarballs
> >>>>>>>>>>>>
> >>>>>>>>>>>> is
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> the primary source now.
Even if someone does have a git
> >>>>>>>>>
> >>>>>>>>> dependency
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> somewhere, they can specify
a branch (actually any ref) in
> >>>>>>
> >>>>>> the
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> <dependency>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> tag. Likewise the command
line.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'm all for moving development
into the master branch.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Braden
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Tue, Apr 22, 2014 at
10:23 AM, Bryan Higgins <
> >>>>>>>>>>>>
> >>>>>>>>>>>> bryan@bryanhiggins.net
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I think the registry
has been around for long enough that
> >>>>>>
> >>>>>> the
> >>>>>>>>>
> >>>>>>>>> vast
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> majority
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> of users won't be installing
directly from git.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Tue, Apr 22, 2014
at 9:44 AM, Ian Clelland <
> >>>>>>>>>>>>
> >>>>>>>>>>>> iclelland@chromium.org
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I totally agree
that we should do this.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think that once
the current plugin release is
> >>>>>
> >>>>> complete,
> >>>>>>
> >>>>>> I
> >>>>>>>
> >>>>>>> can
> >>>>>>>>>>
> >>>>>>>>>> set
> >>>>>>>>>>>>
> >>>>>>>>>>>> up
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> branches so that
the master branch is for development,
> >>>>>
> >>>>> and
> >>>>>>>
> >>>>>>> we
> >>>>>>>>>>
> >>>>>>>>>> can go
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> from
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> there.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Is it a requirement
that plugins be tagged in git for
> >>>>>
> >>>>> npm
> >>>>>>
> >>>>>> to
> >>>>>>>>>>>>
> >>>>>>>>>>>> function?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> thought that the
plugins were uploaded, zipped, to our
> >>>>>>
> >>>>>> couch
> >>>>>>>>>>
> >>>>>>>>>> server,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> each release, and
that there was no further
> >>>>>
> >>>>> communication
> >>>>>>>
> >>>>>>> with
> >>>>>>>>>>
> >>>>>>>>>> the
> >>>>>>>>>>>>
> >>>>>>>>>>>> git
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> repository? It shouldn't
be a problem to go back and
> >>>>>
> >>>>> make
> >>>>>>>
> >>>>>>> sure
> >>>>>>>>>>>>
> >>>>>>>>>>>> they're
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> properly tagged,
but I'm just wondering if it's still a
> >>>>>>>>>>
> >>>>>>>>>> necessity.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Ian
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Apr 21,
2014 at 9:27 PM, Jesse <
> >>>>>>>>>
> >>>>>>>>> purplecabbage@gmail.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I am seeing
more and more pull requests that aren't
> >>>>>
> >>>>> easy
> >>>>>>>>>
> >>>>>>>>> merges
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> because
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> people are starting
their work from the master branch,
> >>>>>>
> >>>>>> and
> >>>>>>>
> >>>>>>> not
> >>>>>>>>>>
> >>>>>>>>>> dev.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We discussed
*a long time ago* that at some point, we
> >>>>>>
> >>>>>> would
> >>>>>>>>>>>>
> >>>>>>>>>>>> consider
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> master
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> to be the bleeding
edge of each plugin, and we could
> >>>>>
> >>>>> then
> >>>>>>>
> >>>>>>> get
> >>>>>>>>>>
> >>>>>>>>>> rid
> >>>>>>>>>>>>
> >>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> dev branches.
 The requirements to make this possible
> >>>>>>>>>
> >>>>>>>>> included,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> using a
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> branch/tag for
every npm release of the plugin, and
> >>>>>>
> >>>>>> making
> >>>>>>>>>
> >>>>>>>>> sure
> >>>>>>>>>>>>
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> plugin
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> dependencies
were correctly mapped.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Has anyone given
this any more thought, and do we have
> >>>>>>
> >>>>>> any
> >>>>>>>>>
> >>>>>>>>> idea
> >>>>>>>>>>>>
> >>>>>>>>>>>> when
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> will make the
switch?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>>> Jesse
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> @purplecabbage
> >>>>>>>>>>>>>>>>>> risingj.com
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Carlos Santana
> >>>> <csantana23@gmail.com>
> >>>
> >>>
> >>
> >
> > --
> > Piotr Zalewa
> > Mozilla
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message