+1 to that.
On Thu, Aug 22, 2013 at 9:40 PM, James Jong <[email protected]> wrote: > +1 to specifying plugins via tag/branch/hash. Having master be the stable > always felt a bit odd to me. > > I think once we have the ability to do this, we could set when to bump the > version at stable release points. I don't think we should be bumping for > every single commit. > > -James Jong > > On Aug 22, 2013, at 1:48 PM, Michal Mocny <[email protected]> wrote: > > > 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 > >>>>> > >>>> > >>> > >> > >
