Policy for individual library versioning
Hi, I wonder whether there is a policy for how to version individual Boost libraries. Should individual libraries follow their own versioning scheme, or should they stick to the Boost versioning scheme? For example, Hana is currently in v0.4 and following Semantic Versioning[1]. I am wondering whether I should change Hana's version to 1.60.0 when it will be released with Boost 1.60.0, and from then on follow that versioning scheme (and drop Semantic Versioning, which I'm OK with). Hence, I would bump to 1.61.0 when Boost 1.61.0 is released, and so on. The other option is to stick with my current versioning scheme and simply document the correspondence between Hana vA.B.C and Boost vX.Y.Z. Is there any agreed-upon way to handle this? Regards, Louis [1]: http://semver.org
On Thu, Oct 15, 2015 at 10:19 AM, Louis Dionne
Hi,
I wonder whether there is a policy for how to version individual Boost libraries. Should individual libraries follow their own versioning scheme, or should they stick to the Boost versioning scheme?
For example, Hana is currently in v0.4 and following Semantic Versioning[1]. I am wondering whether I should change Hana's version to 1.60.0 when it will be released with Boost 1.60.0, and from then on follow that versioning scheme (and drop Semantic Versioning, which I'm OK with). Hence, I would bump to 1.61.0 when Boost 1.61.0 is released, and so on. The other option is to stick with my current versioning scheme and simply document the correspondence between Hana vA.B.C and Boost vX.Y.Z.
Is there any agreed-upon way to handle this?
There is no agreed-upon way so far.. Which means it's up to you. But the common strategy is to have independent versioning. Which is what my own Predef does. And what Spirit, and others do. Whatever you do I would suggest adding a version macro for your library regardless. Examples: < https://github.com/boostorg/predef/blob/master/include/boost/predef/version....
< https://github.com/boostorg/spirit/blob/master/include/boost/spirit/include/...
< https://github.com/boostorg/phoenix/blob/master/include/boost/phoenix/versio...
< https://github.com/boostorg/program_options/blob/master/include/boost/progra...
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera
[...]
There is no agreed-upon way so far.. Which means it's up to you. But the common strategy is to have independent versioning. Which is what my own Predef does. And what Spirit, and others do. Whatever you do I would suggest adding a version macro for your library regardless. Examples:
[...]
Thanks, I'll consider providing a version macro [1], and I'll go with independent versioning. Regards, Louis [1]: https://github.com/ldionne/hana/issues/189
On 15.10.2015 18:19, Louis Dionne wrote:
Hi,
I wonder whether there is a policy for how to version individual Boost libraries. Should individual libraries follow their own versioning scheme, or should they stick to the Boost versioning scheme?
For example, Hana is currently in v0.4 and following Semantic Versioning[1]. I am wondering whether I should change Hana's version to 1.60.0 when it will be released with Boost 1.60.0, and from then on follow that versioning scheme (and drop Semantic Versioning, which I'm OK with). Hence, I would bump to 1.61.0 when Boost 1.61.0 is released, and so on. The other option is to stick with my current versioning scheme and simply document the correspondence between Hana vA.B.C and Boost vX.Y.Z.
Is there any agreed-upon way to handle this?
I don't think there is a Boost-wide policy. Some libraries use both versions, see Boost.Log for instance[1]. The Boost version is convenient for users because for now Boost releases are distributed as a single package. However, if you plan to also release your library separately, you might want to keep your own version numbers as well. This will also help you if Boost transits to a completely modular distribution. [1]: http://www.boost.org/doc/libs/1_59_0/libs/log/doc/html/log/changelog.html
Andrey Semashev
[...]
I don't think there is a Boost-wide policy. Some libraries use both versions, see Boost.Log for instance[1]. The Boost version is convenient for users because for now Boost releases are distributed as a single package. However, if you plan to also release your library separately, you might want to keep your own version numbers as well. This will also help you if Boost transits to a completely modular distribution.
Thanks for the input, that totally makes sense and I like the argument of being able to release the library independently. I'll just keep my current versioning scheme and document the mapping between it and Boost's version, as you do. Regards, Louis
participants (3)
-
Andrey Semashev
-
Louis Dionne
-
Rene Rivera