I'm concerned about who decides when to bump semver version numbers for plugins? How do you define a feature, vs a bugfix? non-backwards-compatible changes are easier to spot, but is a non-user facing improvement a feature or bugfix, say, an api-compatible perf improvement? Plugging a stub implementation? Adding error handling?
Do we bump the version as part of each patch, or do we bump the version once a week based on the changelog for the week prior? -Michal On Mon, Aug 19, 2013 at 2:51 PM, Andrew Grieve <[email protected]> wrote: > Made an issue for this: https://issues.apache.org/jira/browse/CB-4622 > > > On Mon, Aug 19, 2013 at 9:55 AM, Ian Clelland <[email protected] > >wrote: > > > On Mon, Aug 19, 2013 at 9:46 AM, Andrew Grieve <[email protected]> > > wrote: > > > > > Yes, sorry for not being clear - this is all entirely about our own > > > plugins. > > > > > > I liked everything you said Jesse. Only reason I'm suggesting dev vs > > master > > > is because right now that's how plugman works (pulls from master). If > we > > > change plugman to look for a tag (like npm > > > install<https://npmjs.org/doc/cli/npm-install.html>does), then we can > > > change our branch structure. > > > > > > > I think this is worth doing -- Jesse's point is valid, that *always* > > requiring master to be stable imposes a lot on third-party developers. > > > > If we can't pull anything but master, then we can't properly depend on > > specific plugin revisions anyway, so it's going to be useful all around > to > > be able to name branches/tags. > > > > And then we can decide for core plugins whether it makes sense to have > the > > master/dev split, or to do something different. > > > > Ian > > > > > > > > > > On Mon, Aug 19, 2013 at 9:23 AM, Ian Clelland <[email protected] > > > >wrote: > > > > > > > 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 > > > > > > > > > >
