cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jong <wjamesj...@gmail.com>
Subject Re: Post 3.0.0 Releases - Plugins
Date Fri, 23 Aug 2013 01:40:19 GMT
+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 <mmocny@chromium.org> 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 <agrieve@chromium.org> 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 <iclelland@chromium.org
>>> wrote:
>> 
>>> On Mon, Aug 19, 2013 at 9:46 AM, Andrew Grieve <agrieve@chromium.org>
>>> 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 <iclelland@chromium.org
>>>>> wrote:
>>>> 
>>>>> On Mon, Aug 19, 2013 at 4:29 AM, Jesse <purplecabbage@gmail.com>
>>> 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
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message