Please check out the beginning of the conversation [1].
The problem is the fact that hammer module semantic versioning doesn't quite seem to make the most sense,
mostly due the fact that a very large portion of the functionality of our CLI is dictated by the apidoc on the server.
It was suggested that we could version the hammer modules in parity with the versions of the server bits
they respectively get apidoc from. For instance, the hammer module to work with katello-2.2 would be
hammer-cli-katello-2.2. And any modules released between server releases would be appended with a "pre"
(or something denoting that its state is in flux), so a hammer module released after katello-2.2 would be
hammer-cli-katello-2.3-pre, assuming the next release of katello is 2.3.
This versioning scheme would make the most sense if all parties involved implemented the same structure.
So the hammer module for foreman-1.8 that just branched would be hammer-cli-foreman-1.8.
If anybody has an idea of why this may be bad, or they have a different idea, let us know so that we can discuss.
Talking generally, I'm trying to prevent an increase of Foreman
components that follow the core versioning model, as it increases the
size and complexity of the releases. It also prevents these components
from making sensible changes to their version numbers to indicate a
important change when there was no corresponding change to core.
This used to happen in the installer modules and we've only recently
managed to break it apart again, which is working much better.
I'd recommend for Foreman CLI components anyway, for them to follow
their own versioning scheme (e.g. something semver-like) and to
explicitly express compatibility with certain Foreman versions. I'm not
saying that a single version has to support every possible server-side
version, but that separate version numbers work better.
···
On 06/03/15 17:28, Adam Price wrote:
> Devs,
>
> Please check out the beginning of the conversation [1].
>
> The problem is the fact that hammer module semantic versioning doesn't quite seem to make the most sense,
> mostly due the fact that a very large portion of the functionality of our CLI is dictated by the apidoc on the server.
>
> It was suggested that we could version the hammer modules in parity with the versions of the server bits
> they respectively get apidoc from. For instance, the hammer module to work with katello-2.2 would be
> hammer-cli-katello-2.2. And any modules released between server releases would be appended with a "pre"
> (or something denoting that its state is in flux), so a hammer module released after katello-2.2 would be
> hammer-cli-katello-2.3-pre, assuming the next release of katello is 2.3.
>
> This versioning scheme would make the most sense if all parties involved implemented the same structure.
> So the hammer module for foreman-1.8 that just branched would be hammer-cli-foreman-1.8.
>
> If anybody has an idea of why this may be bad, or they have a different idea, let us know so that we can discuss.
> > Devs,
> >
> > Please check out the beginning of the conversation [1].
> >
> > The problem is the fact that hammer module semantic versioning doesn't
> > quite seem to make the most sense,
> > mostly due the fact that a very large portion of the functionality of our
> > CLI is dictated by the apidoc on the server.
> >
> > It was suggested that we could version the hammer modules in parity with
> > the versions of the server bits
> > they respectively get apidoc from. For instance, the hammer module to work
> > with katello-2.2 would be
> > hammer-cli-katello-2.2. And any modules released between server releases
> > would be appended with a "pre"
> > (or something denoting that its state is in flux), so a hammer module
> > released after katello-2.2 would be
> > hammer-cli-katello-2.3-pre, assuming the next release of katello is 2.3.
> >
> > This versioning scheme would make the most sense if all parties involved
> > implemented the same structure.
> > So the hammer module for foreman-1.8 that just branched would be
> > hammer-cli-foreman-1.8.
> >
> > If anybody has an idea of why this may be bad, or they have a different
> > idea, let us know so that we can discuss.
>
> Talking generally, I'm trying to prevent an increase of Foreman
> components that follow the core versioning model, as it increases the
> size and complexity of the releases. It also prevents these components
> from making sensible changes to their version numbers to indicate a
> important change when there was no corresponding change to core.
>
> This used to happen in the installer modules and we've only recently
> managed to break it apart again, which is working much better.
>
> I'd recommend for Foreman CLI components anyway, for them to follow
> their own versioning scheme (e.g. something semver-like) and to
> explicitly express compatibility with certain Foreman versions. I'm not
> saying that a single version has to support every possible server-side
> version, but that separate version numbers work better.
>
> –
> Dominic Cleal
> Red Hat Engineering
>
To clarify my understanding, you're suggesting not to change the hammer
modules' current versioning scheme, but instead to denote somewhere – maybe in the
gem's description – which specific versions of the server they are
compatible with? Or possibly with stricter gem dependencies?
···
----- Original Message -----
> On 06/03/15 17:28, Adam Price wrote:
Correct. gem dependencies won't work unfortunately as you can't depend
on a gem in the remote Foreman service.
We could also add something to help reinforce/indicate compatibility at
the API layer?
···
On 09/03/15 14:16, Adam Price wrote:
> ----- Original Message -----
>> On 06/03/15 17:28, Adam Price wrote:
>>> Devs,
>>>
>>> Please check out the beginning of the conversation [1].
>>>
>>> The problem is the fact that hammer module semantic versioning doesn't
>>> quite seem to make the most sense,
>>> mostly due the fact that a very large portion of the functionality of our
>>> CLI is dictated by the apidoc on the server.
>>>
>>> It was suggested that we could version the hammer modules in parity with
>>> the versions of the server bits
>>> they respectively get apidoc from. For instance, the hammer module to work
>>> with katello-2.2 would be
>>> hammer-cli-katello-2.2. And any modules released between server releases
>>> would be appended with a "pre"
>>> (or something denoting that its state is in flux), so a hammer module
>>> released after katello-2.2 would be
>>> hammer-cli-katello-2.3-pre, assuming the next release of katello is 2.3.
>>>
>>> This versioning scheme would make the most sense if all parties involved
>>> implemented the same structure.
>>> So the hammer module for foreman-1.8 that just branched would be
>>> hammer-cli-foreman-1.8.
>>>
>>> If anybody has an idea of why this may be bad, or they have a different
>>> idea, let us know so that we can discuss.
>>
>> Talking generally, I'm trying to prevent an increase of Foreman
>> components that follow the core versioning model, as it increases the
>> size and complexity of the releases. It also prevents these components
>> from making sensible changes to their version numbers to indicate a
>> important change when there was no corresponding change to core.
>>
>> This used to happen in the installer modules and we've only recently
>> managed to break it apart again, which is working much better.
>>
>> I'd recommend for Foreman CLI components anyway, for them to follow
>> their own versioning scheme (e.g. something semver-like) and to
>> explicitly express compatibility with certain Foreman versions. I'm not
>> saying that a single version has to support every possible server-side
>> version, but that separate version numbers work better.
>>
>> --
>> Dominic Cleal
>> Red Hat Engineering
>>
>
> To clarify my understanding, you're suggesting not to change the hammer
> modules' current versioning scheme, but instead to denote somewhere -- maybe in the
> gem's description -- which specific versions of the server they are
> compatible with? Or possibly with stricter gem dependencies?
The api returns version of the core in headers. Adding plugin versions
would be helpful too. Than we can compare it on the plugin or command level.
T.
···
On 03/09/2015 03:19 PM, Dominic Cleal wrote:
> On 09/03/15 14:16, Adam Price wrote:
>> ----- Original Message -----
>>> On 06/03/15 17:28, Adam Price wrote:
>>>> Devs,
>>>>
>>>> Please check out the beginning of the conversation [1].
>>>>
>>>> The problem is the fact that hammer module semantic versioning doesn't
>>>> quite seem to make the most sense,
>>>> mostly due the fact that a very large portion of the functionality of our
>>>> CLI is dictated by the apidoc on the server.
>>>>
>>>> It was suggested that we could version the hammer modules in parity with
>>>> the versions of the server bits
>>>> they respectively get apidoc from. For instance, the hammer module to work
>>>> with katello-2.2 would be
>>>> hammer-cli-katello-2.2. And any modules released between server releases
>>>> would be appended with a "pre"
>>>> (or something denoting that its state is in flux), so a hammer module
>>>> released after katello-2.2 would be
>>>> hammer-cli-katello-2.3-pre, assuming the next release of katello is 2.3.
>>>>
>>>> This versioning scheme would make the most sense if all parties involved
>>>> implemented the same structure.
>>>> So the hammer module for foreman-1.8 that just branched would be
>>>> hammer-cli-foreman-1.8.
>>>>
>>>> If anybody has an idea of why this may be bad, or they have a different
>>>> idea, let us know so that we can discuss.
>>>
>>> Talking generally, I'm trying to prevent an increase of Foreman
>>> components that follow the core versioning model, as it increases the
>>> size and complexity of the releases. It also prevents these components
>>> from making sensible changes to their version numbers to indicate a
>>> important change when there was no corresponding change to core.
>>>
>>> This used to happen in the installer modules and we've only recently
>>> managed to break it apart again, which is working much better.
>>>
>>> I'd recommend for Foreman CLI components anyway, for them to follow
>>> their own versioning scheme (e.g. something semver-like) and to
>>> explicitly express compatibility with certain Foreman versions. I'm not
>>> saying that a single version has to support every possible server-side
>>> version, but that separate version numbers work better.
>>>
>>> --
>>> Dominic Cleal
>>> Red Hat Engineering
>>>
>>
>> To clarify my understanding, you're suggesting not to change the hammer
>> modules' current versioning scheme, but instead to denote somewhere -- maybe in the
>> gem's description -- which specific versions of the server they are
>> compatible with? Or possibly with stricter gem dependencies?
>
> Correct. gem dependencies won't work unfortunately as you can't depend
> on a gem in the remote Foreman service.
>
> We could also add something to help reinforce/indicate compatibility at
> the API layer?
>
Sorry to re-hash the thread, but I got to thinking about this again with
respect to a recent fix I made. What about proposing that Hammer modules
follow the same suggested semver policy as suggested for plugins? And by
proposing, I mean adding to the plugin or another such wiki page dedicated
to hammer if such exists. I am more than happy to add to the proper
location assuming we are in agreement with respect to encouraging this (I
would just need pointing to proper location).
Assuming the above, and from prior comments, I'd gather that if there is a
plugin that exists with a CLI component, that the authors shouldn't attempt
to keep the two in version lockstep (e.g. foreman_foo 2.0.0 and
hammer-cli-foo 2.0.0) ?
Eric
···
On Mon, Mar 9, 2015 at 11:24 AM, Tomas Strachota wrote:
On 03/09/2015 03:19 PM, Dominic Cleal wrote:
On 09/03/15 14:16, Adam Price wrote:
----- Original Message -----
On 06/03/15 17:28, Adam Price wrote:
Devs,
Please check out the beginning of the conversation [1].
The problem is the fact that hammer module semantic versioning doesn’t
quite seem to make the most sense,
mostly due the fact that a very large portion of the functionality of
our
CLI is dictated by the apidoc on the server.
It was suggested that we could version the hammer modules in parity
with
the versions of the server bits
they respectively get apidoc from. For instance, the hammer module to
work
with katello-2.2 would be
hammer-cli-katello-2.2. And any modules released between server
releases
would be appended with a “pre”
(or something denoting that its state is in flux), so a hammer module
released after katello-2.2 would be
hammer-cli-katello-2.3-pre, assuming the next release of katello is
2.3.
This versioning scheme would make the most sense if all parties
involved
implemented the same structure.
So the hammer module for foreman-1.8 that just branched would be
hammer-cli-foreman-1.8.
If anybody has an idea of why this may be bad, or they have a different
idea, let us know so that we can discuss.
Talking generally, I’m trying to prevent an increase of Foreman
components that follow the core versioning model, as it increases the
size and complexity of the releases. It also prevents these components
from making sensible changes to their version numbers to indicate a
important change when there was no corresponding change to core.
This used to happen in the installer modules and we’ve only recently
managed to break it apart again, which is working much better.
I’d recommend for Foreman CLI components anyway, for them to follow
their own versioning scheme (e.g. something semver-like) and to
explicitly express compatibility with certain Foreman versions. I’m not
saying that a single version has to support every possible server-side
version, but that separate version numbers work better.
–
Dominic Cleal
Red Hat Engineering
To clarify my understanding, you’re suggesting not to change the hammer
modules’ current versioning scheme, but instead to denote somewhere –
maybe in the
gem’s description – which specific versions of the server they are
compatible with? Or possibly with stricter gem dependencies?
Correct. gem dependencies won’t work unfortunately as you can’t depend
on a gem in the remote Foreman service.
We could also add something to help reinforce/indicate compatibility at
the API layer?
The api returns version of the core in headers. Adding plugin versions
would be helpful too. Than we can compare it on the plugin or command level.
