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 <[email protected]>wrote: > > > On Apr 23, 2014, at 7:16 AM, Carlos Santana <[email protected]> > 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/[email protected]"; > > Yes, this. > > > > > --Carlos > > > > > > > >> On Wed, Apr 23, 2014 at 9:30 AM, Michal Mocny <[email protected]> > wrote: > >> > >> Also, it will only "break" new plugin installs. > >> > >> > >> On Tue, Apr 22, 2014 at 9:55 PM, Ian Clelland <[email protected] > >>> 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 <[email protected]> > >>> wrote: > >>> > >>>> Didn't know about npm deprecate. Makes sense to me! > >>>> > >>>>> On Tue, Apr 22, 2014 at 7:09 PM, Shazron <[email protected]> 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 <[email protected]> > >>>>> 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 <[email protected]> > >>> wrote: > >>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> On Tue, Apr 22, 2014 at 11:30 AM, Shazron <[email protected]> > >>> wrote: > >>>>>>>> +1++ > >>>>>>>> > >>>>>>>> > >>>>>>>> On Tue, Apr 22, 2014 at 10:55 AM, Steven Gill < > >>>> [email protected] > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> +1! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, Apr 22, 2014 at 10:02 AM, James Jong < > >>> [email protected] > >>>>> > >>>>>>> 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 < > >>>> [email protected]> > >>>>>>>>> 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 < > >>>>>>>>>> [email protected]>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 < > >>>>>>>>> [email protected] > >>>>>>>>>>>>> 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 < > >>>>>>>>> [email protected] > >>>>>>>>>>>>>> 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 < > >>>>>> [email protected]> > >>>>>>>>>>>> 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 > > <[email protected]> >
