cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: [DISCUSS] Plugin master branches
Date Thu, 24 Apr 2014 15:56:45 GMT
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>
>

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