Update pin for boost

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update the pin for boost. The current pinned version is 1.74.0, the latest available version is 1.80.0 and the max pin pattern is x.x.x. This migration will impact 93 feedstocks.

Checklist:

• The new version is a stable supported pin.
• I checked that the ABI changed from 1.74.0 to 1.80.0.

**Please note that if you close this PR we presume that the new pin has been rejected.

@conda-forge-admin please ping boost
This PR was generated by https://github.com/regro/autotick-bot/actions/runs/2881043390, please use this URL for debugging

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/boost and so here I am doing that.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[hmaarrfk]

Any objections to this?

[beckermr]

Do we want to support both the current and this version for a while?

[beckermr]

We have done this commonly in the past.

[hmaarrfk]

i think that is desirable given it is a long migration. Is it any different than just adding two entries

boost:
- 1.78
- 1.80

[beckermr]

No different. That's perfect!

[hmaarrfk]

Why does boost not have a run export?

[beckermr]

I'm confused on that too. Many times it is header-only and so doesn't need one.

[hmaarrfk]

I'm confused on that too. Many times it is header-only and so doesn't need one.

I would rather users opt out of the pinning, rather than then opt-in, at least until we get a "boost header only package"

[beckermr]

We need to consult core. We've had this discussion before and there was not agreement.

[beckermr]

@conda-forge/core

[hmaarrfk]

I think the comments below should be addressed first.

• Rebuild 1.80 with newer compilers & enable 1.78 migrations boost-cpp-feedstock#129
• Rebuild 1.78 with newer compilers boost-cpp-feedstock#130

[jakirkham]

In the past what we did is only support one version, but leave the migration running for a while until we could switch. That said, no strong feelings about this or other approaches

[h-vetinari]

We need to consult core. We've had this discussion before and there was not agreement.

See conda-forge/boost-cpp-feedstock#82.

There was some discussion not too long ago about splitting between the header-only ouput and the full lib, where @isuruf said at the time:

Only major thing we have to do is to write a migrator to go from boost-cpp -> libboost or boost-headers depending on if run had boost-cpp or not.

[h-vetinari]

i think that is desirable given it is a long migration.

I wasn't too involved, but I had the impression with 1.74 -> 1.78 that this wasn't actually as painful / longwinded as feared? It's not that long ago either (~3 month).

[jakirkham]

As someone involved in that migration, it was fairly long running / painful. It also got coupled with the Python 3.11 migration, which made things tricky.

Personally would be ok pushing off a Boost migration for a bit. Would be good to get some of the existing things off of our plates.

[h-vetinari]

Closing this as obsolete