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 <purplecabb...@gmail.com>wrote:
On Apr 23, 2014, at 7:16 AM, Carlos Santana <csantan...@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 <mmo...@chromium.org>
wrote:
Also, it will only "break" new plugin installs.
On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland <iclell...@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 <agri...@chromium.org>
wrote:
Didn't know about npm deprecate. Makes sense to me!
On Tue, Apr 22, 2014 at 7:09 PM, Shazron <shaz...@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.ka...@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 <bows...@gmail.com>
wrote:
+1
On Tue, Apr 22, 2014 at 11:30 AM, Shazron <shaz...@gmail.com>
wrote:
+1++
On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill <
stevengil...@gmail.com
wrote:
+1!
On Tue, Apr 22, 2014 at 10:02 AM, James Jong <
wjamesj...@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 <
agri...@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 <
bra...@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 <
br...@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 <
iclell...@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 <
purplecabb...@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
<csantan...@gmail.com>
--
Piotr Zalewa
Mozilla
