Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.: <engine min-cdv-version="2.8" max-cdv-version="2.8"> <default-git-ref>refs/head/2.8.x</default-git-ref> </engine> <engine min-cdv-version="2.9"> <default-git-ref>refs/tags/stable</default-git-ref> </engine>
Then, when someone plugman installs the git URL, it can fetch it and checkout a version that best matches your cordova version. Then, when you update your cordova version, it can go through your plugins and update them to different branches (unless you glue them to a ref as a part of your install URL) On Mon, Jul 22, 2013 at 2:44 PM, Braden Shepherdson <bra...@chromium.org>wrote: > The model I had always imagined was that we would do something similar to > npm: Plugin authors decide what the default ref is for their plugin. Could > be master, some other branch, a tag, a hash. That's what the discovery tool > will return when a user asks to add that plugin without explicitly > specifying a version. I think this is a good idea we should implement too. > > Braden > > > On Fri, Jul 19, 2013 at 10:16 AM, Andrew Grieve <agri...@chromium.org > >wrote: > > > I think it's true that: > > > > 1. CLI downloads tagged versions of platforms > > 2. Plugman downloads plugins from "master" branch > > > > This means that we can't check any code into plugin master branches > without > > them going live immediately. > > > > Best solution would be to change plugman to download from a tag by > default, > > but a bit late for that now... > > > > Instead, I think we should change all development on plugins: > > - Commit only to "dev" branch. > > - When we want to push an update, we should file a release bug for the > > plugin, test on all platforms > > Case 1: The changes work with 3.0 cordova: then merge into master (only > if > > it works of course) > > Case 2: The changes require a platform API that hasn't been release yet: > > Wait and release after the next cordova core release. > > > > > > Any other ideas? > > >
