Re: Maintenance of BOOST_GIL_VERSION

Subject: Re: Maintenance of BOOST_GIL_VERSION
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2019-03-26 12:50:22

On Mon, 25 Mar 2019 at 20:25, stefan <stefan_at_[hidden]> wrote:
> On 2019-03-25 4:13 p.m., Mateusz Loskot wrote:
> >
> > Shouldn't we increase the version with every Boost release
> > that delivers any changes to GIL code?
> >
> > The version is described [1]:
> >
> > /// This is a simple integer that is incremented by one every
> > /// time a set of code changes is merged to the develop branch.
> > #define BOOST_GIL_VERSION 22
> >
> > Assuming the description is correct, then every time we merge
> > new non-trivial changes from GIL's develop to master for release
> > with new Boost version, the BOOST_GIL_VERSION should be
> > increased, no?
> >
> > [1] https://github.com/boostorg/gil/blob/develop/include/boost/gil/version.hpp
>
> It isn't entirely clear to me what the purpose of that version number
> is, i.e. what exactly we want it to capture.

It's neither clear to me.
Also, why 2.2 becomes 22 and not calculated in more robust manner like
https://github.com/boostorg/config/blob/develop/include/boost/version.hpp
What if 2.10 is reached?

> But in the absence of any
> more robust version scheme, I agree, we should bump it.

Shall we bump 22 to 23 and 2_2 to 2_3 now in develop?
Do we still have time to merge into master for 1.70?

> A slightly improved versioning mechanism would generate the
> `version.hpp` header using something akin to `git describe --tags
> --long`, so the version would contain a mix of tagged version string and
> SHA, which allows to easily look up the commit corresponding to the
> current version.

Yes, that is a good idea.
What/who should generate boost/gil/version.hpp, when?
If GIL was not header-only, it would be natural to generate it during build.

Perhaps the original plan of GIL's authors was to use BOOST_GIL_VERSION
to indicate compatibility, points of breaking changes.
AFAIU, in Boost, no compatibility is guaranteed and GIL may introduce
breaking changes between 1.69 and 1.70
So, BOOST_GIL_VERSION does not seem to be much usable apart from
identification purposes - e.g. what is snapshot of GIL a user is
reporting a bug to.
Am I correct?

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net