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 18:21:31 GMT
This is now done. Buildbot will be broken until we update it to always use
master plugin branches; otherwise everything should be okay.

For the morbidly curious:

$ cordova-coho/coho repo-update -r plugins
$ cordova-coho/coho foreach -r plugins "git checkout master; git merge dev"
$ echo -e "\nThis is \`dev\` - the deprecated development branch of this
plugin; development of this plugin has moved to the \`master\` branch" >>
notice
$ cordova-coho/coho o foreach -r plugins "git checkout dev; git rm -r *;
git checkout HEAD -- README.md; cat ../notice >> README.md; git add
README.md; git commit -m 'CB-6521: Remove development branch'"
$ cordova-coho/coho repo-push -r plugins


On Fri, Apr 25, 2014 at 12:05 PM, Andrew Grieve <agrieve@chromium.org>wrote:

> Sounds good! There are a couple tweaks to coho to remove (yay) special
> casing of plugin repos. I can make that change once you're done.
>
> Go for a rm -r commit on dev instead of removing the HEAD right away,
> because I *think* if you delete the remote branch, then someone can
> easily (and accidentally) re-push their version of dev up.
>
>
> On Fri, Apr 25, 2014 at 11:47 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> > On Fri, Apr 25, 2014 at 11:42 AM, Ian Clelland <iclelland@chromium.org
> >wrote:
> >
> >> 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.
> >>
> > +1 to that idea.
> >
> >>
> >>
> >> 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