On Mon, Aug 19, 2013 at 4:29 AM, Jesse <[email protected]> wrote:
> Okay, took me awhile to get this out, I should know better than to promise > to start a new threads on Friday afternoon. XD > > Split from 'Releases in a 3.0 World' > > RE: Pasted => > > > cordova-plugins: > > - Commit only to the `dev` branch > > - Use semver for them. > ... I don't think that we should dictate what we expect the community to do > with their own plugins. Here's some alternative thoughts: > All good ideas, I think. To be fair, though, I think that Andrew's original proposal was specifically about core plugins, and how we version / release those. > > a) versioning is done however the developer of the plugin wants to do it, > for core plugins, because they are within our control and we ARE 'the > developer' we will use semver. > Agreed. See above. > b) plugman needs to gain the ability to install any particular version of a > plugin, just like a plugin can depend on a specific version of another > plugin, we need to be able do this directly. > Probably some kind of standard git url that names both the repo and the branch / tag. > c) do not enforce the use of a dev branch, master should be considered a > work in progress, we have already had issues where 1 broken push to master > [1] broke the plugin for all platforms. > This will probably depend on (b), although we could also get the same effect by developing on master, and having plugman pull from a named "stable" branch (or some other named branch). Of course, if we want to support third-party plugins as well, without dictating to them, then we should probably be able to just tell plugman which branch to pull from for any given plugin. > - My personal expectation of a 'master' branch is that tests are passing, > but it is still the bleeding edge, and I should use it at my own risk. > - If we want to suggest a tested latest version, in production, I think we > should use a tag or branch of 'latest-stable' or something similar. > - also, plugman should be aware of version via tags or branches, and not > blindly pull from master, this would likely be handled at plugin > registration time. ( as in b above ) Then we can test a plugin's > integration with other plugins before pushing it live. > > The rest of the initial proposal is about process, which I don't think we > govern for plugin developers. We can certainly adopt something like this > for the core plugins, but I think we should let the process evolve, and not > pretend we know what will happen next. > > I am not completely sold on the above, some of this is just me thinking out > loud, the main thing I worry is just that we may not have enough info to > fully define this ( at least the process stuff), and I think it definitely > needs more discussion, and even maybe some experimentation. > Ian
