Hi all,
In discussion with the rest of the Discovery team, along with sage
advice from Dominic, we've come to the conclusion that we'll need to
bump the major version of the discovery plugin every time we change
the minimum version of Foreman that we require in the plugin.
To illustrate, we've just released 2.0.0, which is only compatible
with Foreman 1.7. If we now release the next version (for core-1.8) as
discovery-2.1.0, we'll have no suitable version to use if we decide to
backport new features to the core-1.7-compat branch (since, via
semver, z-stream is for bug fixes, not features). In other words,
create a new major version any time we alter this line:
lib/foreman_discovery/engine.rb:39: requires_foreman '~> 1.7.0'
Discovery is already planning to do this. My question to the
collective is: should we make this the recommended versioning for all
plugins (i.e, when to bump the x-component of x.y.z)? I can easily
update the wiki and the template plugin, but I thought I'd get
opinions first.
Greg
Why could you not use 2.0.1 for 1.7 changes and 2.1.0 for 1.8?
– bk
···
On 02/09/2015 11:35 AM, Greg Sutcliffe wrote:
> Hi all,
>
> In discussion with the rest of the Discovery team, along with sage
> advice from Dominic, we've come to the conclusion that we'll need to
> bump the major version of the discovery plugin every time we change
> the minimum version of Foreman that we require in the plugin.
>
> To illustrate, we've just released 2.0.0, which is only compatible
> with Foreman 1.7. If we now release the next version (for core-1.8) as
> discovery-2.1.0, we'll have no suitable version to use if we decide to
> backport new features to the core-1.7-compat branch (since, via
> semver, z-stream is for bug fixes, not features). In other words,
> create a new major version any time we alter this line:
>
> lib/foreman_discovery/engine.rb:39: requires_foreman '~> 1.7.0'
>
> Discovery is already planning to do this. My question to the
> collective is: should we make this the recommended versioning for all
> plugins (i.e, when to bump the x-component of x.y.z)? I can easily
> update the wiki and the template plugin, but I thought I'd get
> opinions first.
>
> Greg
>
2.0.1 would be the first bugfix release for the 2.0 series, as per
Greg
···
On 9 February 2015 at 21:15, Bryan Kearney wrote:
>
>
> On 02/09/2015 11:35 AM, Greg Sutcliffe wrote:
>>
>> Hi all,
>>
>> In discussion with the rest of the Discovery team, along with sage
>> advice from Dominic, we've come to the conclusion that we'll need to
>> bump the major version of the discovery plugin every time we change
>> the minimum version of Foreman that we require in the plugin.
>>
>> To illustrate, we've just released 2.0.0, which is only compatible
>> with Foreman 1.7. If we now release the next version (for core-1.8) as
>> discovery-2.1.0, we'll have no suitable version to use if we decide to
>> backport new features to the core-1.7-compat branch (since, via
>> semver, z-stream is for bug fixes, not features). In other words,
>> create a new major version any time we alter this line:
>>
>> lib/foreman_discovery/engine.rb:39: requires_foreman '~> 1.7.0'
>>
>> Discovery is already planning to do this. My question to the
>> collective is: should we make this the recommended versioning for all
>> plugins (i.e, when to bump the x-component of x.y.z)? I can easily
>> update the wiki and the template plugin, but I thought I'd get
>> opinions first.
>>
>> Greg
>>
> Why could you not use 2.0.1 for 1.7 changes and 2.1.0 for 1.8?
2.1.0 for 1.8 would mean that it's backwards compatible with 1.7
(because 2.0 is compatible with 1.7), which wouldn't be the case if we
wanted to follow semantic versioning, and users would probably not be
happy about it. When we pin gems to '~> X.Y' we expect all updates to
be backwards compatible with X.
I think the recommendation absolutely makes sense, changing the
minimum Foreman version required is almost a definition of breaking
backwards compatibility for plugins. The plugin wiki in fact mentions
that in the release strategies section [1].
Just as a reminder it's not strictly necessary to bump a major
version/change minimum required version if the plugin doesn't use any
new features/helpers/whatever in core that were not introduced in
Foreman.
[1] How to Create a Plugin - Foreman
···
On Mon, Feb 9, 2015 at 11:49 PM, Greg Sutcliffe wrote:
> On 9 February 2015 at 21:15, Bryan Kearney wrote:
>>
>>
>> On 02/09/2015 11:35 AM, Greg Sutcliffe wrote:
>>>
>>> Hi all,
>>>
>>> In discussion with the rest of the Discovery team, along with sage
>>> advice from Dominic, we've come to the conclusion that we'll need to
>>> bump the major version of the discovery plugin every time we change
>>> the minimum version of Foreman that we require in the plugin.
>>>
>>> To illustrate, we've just released 2.0.0, which is only compatible
>>> with Foreman 1.7. If we now release the next version (for core-1.8) as
>>> discovery-2.1.0, we'll have no suitable version to use if we decide to
>>> backport new features to the core-1.7-compat branch (since, via
>>> semver, z-stream is for bug fixes, not features). In other words,
>>> create a new major version any time we alter this line:
>>>
>>> lib/foreman_discovery/engine.rb:39: requires_foreman '~> 1.7.0'
>>>
>>> Discovery is already planning to do this. My question to the
>>> collective is: should we make this the recommended versioning for all
>>> plugins (i.e, when to bump the x-component of x.y.z)? I can easily
>>> update the wiki and the template plugin, but I thought I'd get
>>> opinions first.
>>>
>>> Greg
>>>
>> Why could you not use 2.0.1 for 1.7 changes and 2.1.0 for 1.8?
>
> 2.0.1 would be the first bugfix release for the 2.0 series, as per
> http://semver.org
>
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato
@elobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> I think the recommendation absolutely makes sense, changing the
> minimum Foreman version required is almost a definition of breaking
> backwards compatibility for plugins. The plugin wiki in fact mentions
> that in the release strategies section [1].
> [1] How to Create a Plugin - Foreman
It follows on from this that I encourage branching per major version
rather trying to maintain multi-Foreman version compatibility on a
single branch. We can easily set up Jenkins jobs to test stable
branches and PRs against stable Foreman branches (though not one branch
to multi-version), e.g. Discovery's 2.0-stable is tested against 1.7-stable.
> Just as a reminder it's not strictly necessary to bump a major
> version/change minimum required version if the plugin doesn't use any
> new features/helpers/whatever in core that were not introduced in
> Foreman.
Indeed. If you look at our deb/RPM packages, many plugins were built
against a nightly from a few major releases ago and still work fine.
Some plugins use new features or rely on fixes in every release, so they
increment faster, but it varies from plugin to plugin.
···
On 10/02/15 07:04, Daniel Lobato wrote:
–
Dominic Cleal
Red Hat Engineering
Gah! How did I miss that? I was sure we didn't have that written down.
Apparently I can't read. So that's one less item to do. Are we
thinking we should add something to the template plugin too, just to
highlight this?
Greg
···
On 10 February 2015 at 07:04, Daniel Lobato wrote:
> I think the recommendation absolutely makes sense, changing the
> minimum Foreman version required is almost a definition of breaking
> backwards compatibility for plugins. The plugin wiki in fact mentions
> that in the release strategies section [1].
Maybe add a few words of advice about it & semver here?
···
On 10/02/15 10:26, Greg Sutcliffe wrote:
> On 10 February 2015 at 07:04, Daniel Lobato wrote:
>> I think the recommendation absolutely makes sense, changing the
>> minimum Foreman version required is almost a definition of breaking
>> backwards compatibility for plugins. The plugin wiki in fact mentions
>> that in the release strategies section [1].
>
> Gah! How did I miss that? I was sure we didn't have that written down.
> Apparently I can't read. So that's one less item to do. Are we
> thinking we should add something to the template plugin too, just to
> highlight this?
–
Dominic Cleal
Red Hat Engineering
