So far, versions are updated, in all packages that do have versions, to the
orocos toolchain's release version.
Since I do plan to start versioning the packages that I maintain, I would
personally much much prefer going for semantic versioning (http://semver.org
).
FYI, what triggered this message is this issue:
https://github.com/orocos-toolchain/utilmm/issues/1
Sylvain
Versioning
On Thu, Jul 10, 2014 at 12:27 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
> So far, versions are updated, in all packages that do have versions, to the
> orocos toolchain's release version.
>
> Since I do plan to start versioning the packages that I maintain, I would
> personally much much prefer going for semantic versioning
> (http://semver.org).
>
> FYI, what triggered this message is this issue:
> https://github.com/orocos-toolchain/utilmm/issues/1
Semantic versioning is the reason that the 2.7.0 official release has
been postponed for a long time, since we added source-compatible, but
binary incompatible changes (adding virtual functions mostly, or
adding default arguments). Each such change would have required a
2.N+1 release, once it was branched from master. We solved it by
always building from source and sticking to master.
Apart from that, I agree that sem ver is the clearest and most
necessary thing to do such that users can rely on this when upgrading
their toolchain.
Peter
Versioning
On Jul 10, 2014, at 06:36 , Peter Soetens <peter [..] ...> wrote:
> On Thu, Jul 10, 2014 at 12:27 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>> So far, versions are updated, in all packages that do have versions, to the
>> orocos toolchain's release version.
>>
>> Since I do plan to start versioning the packages that I maintain, I would
>> personally much much prefer going for semantic versioning
>> (http://semver.org).
>>
>> FYI, what triggered this message is this issue:
>> https://github.com/orocos-toolchain/utilmm/issues/1
>
> Semantic versioning is the reason that the 2.7.0 official release has
> been postponed for a long time, since we added source-compatible, but
> binary incompatible changes (adding virtual functions mostly, or
> adding default arguments). Each such change would have required a
> 2.N+1 release, once it was branched from master. We solved it by
> always building from source and sticking to master.
Why do you propose *multiple* releases? Why not batch up a pile of these binary incompatible changes, and then release 2.7.0?
> Apart from that, I agree that sem ver is the clearest and most
> necessary thing to do such that users can rely on this when upgrading
> their toolchain.
>
> Peter
So perhaps the question is "when" are packages released? Semver gives a formal spec on how versions should be numbered; it says nothing about the process that *we* use to release packages. The lack of release of 2.7.0 of the toolchain is a major problem for those of us who need stability. So what are our rules/process to deal with this?
Cheers
S
Versioning
2014-07-10 12:56 GMT+02:00 S Roderick <kiwi [dot] net [..] ...>:
> On Jul 10, 2014, at 06:36 , Peter Soetens <peter [..] ...> wrote:
>
>> On Thu, Jul 10, 2014 at 12:27 PM, Sylvain Joyeux <sylvain [dot] joyeux [..] ...> wrote:
>>> So far, versions are updated, in all packages that do have versions, to the
>>> orocos toolchain's release version.
>>>
>>> Since I do plan to start versioning the packages that I maintain, I would
>>> personally much much prefer going for semantic versioning
>>> (http://semver.org).
>>>
>>> FYI, what triggered this message is this issue:
>>> https://github.com/orocos-toolchain/utilmm/issues/1
>>
>> Semantic versioning is the reason that the 2.7.0 official release has
>> been postponed for a long time, since we added source-compatible, but
>> binary incompatible changes (adding virtual functions mostly, or
>> adding default arguments). Each such change would have required a
>> 2.N+1 release, once it was branched from master. We solved it by
>> always building from source and sticking to master.
>
> Why do you propose *multiple* releases? Why not batch up a pile of these binary incompatible changes, and then release 2.7.0?
>
=> "would have required", not will require ;p
2.7 is in the pipe for too long due to this integration.
>> Apart from that, I agree that sem ver is the clearest and most
>> necessary thing to do such that users can rely on this when upgrading
>> their toolchain.
>>
>> Peter
>
> So perhaps the question is "when" are packages released? Semver gives a formal spec on how versions should be numbered; it says nothing about the process that *we* use to release packages. The lack of release of 2.7.0 of the toolchain is a major problem for those of us who need stability. So what are our rules/process to deal with this?
>
> Cheers
> S
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev