changelog for this force push

the typing for error() is too long a callable that should also specify the types of error() itself first so let's just drop it for now until the time for it comes oh noes oh gosh

changelog for this force push

add to changelog

Previous actions run (success): https://github.com/cpplint/cpplint/actions/runs/14022517156?pr=353

In our code base it solves the issues with members initializers, but there is one issue remaining:

#include "types.hpp"

namespace opossum {

namespace hana = boost::hana;

namespace detail {

// Extends to hana::make_tuple(hana::type_c<int32_t>, hana::type_c<int64_t>, ...);
static constexpr auto types =
    hana::make_tuple(BOOST_PP_SEQ_ENUM(BOOST_PP_SEQ_TRANSFORM(EXPAND_TO_HANA_TYPE, _, data_types_macro)));

cpplint complains about the last line.

I don't think we would bother with that, unfortunately... catching that would probably make cpplint way slower and the usual linesplitting AFAIK is to split inside the parentheses like

static constexpr auto types = hana::make_tuple(BOOST_PP_SEQ_ENUM(
    BOOST_PP_SEQ_TRANSFORM(EXPAND_TO_HANA_TYPE, _, data_types_macro)));

which is also what clang-format with Google style gives you.

Okay, we'll just NOLINT this line then.

Thanks for the quick fix with this PR!

force-push changelog

• rebased for suppress C++-only categories on C file extensions #318
• fix PR number for suppress C++-only categories on C file extensions #318

@cclauss Please review.

Rebase includes typo fix. Pls review

This has now been sitting here for 2 weeks. I can rebase after #334 is merged to add a new changelog section.

Please resolve the git conflict in CHANGELOG.rst, and then I will approve this pull request.

Great! Thanks. However rebasing is blocked by #334, which would bump the version and add a new block in the changelog.

#334 is now merged. Updating the version should only be done in the release process, not before. Modifying CHANGELOG.rst is always dicey because of git conflicts. My recommendation would be that new entries only pertain to the current pull request. Put a blank line before and after all new entries (to decrease the possibility of git conflicts).

At release time, we can update the version and remove the blank lines.

What is release vNEXT? Is it v2.0.2, v2.1.0, or v3.0.0? Different pull requests making different guesses is suboptimal (git conflicts). It is best to make the vNEXT version number decision at release time.
v2.0.1 is preserved at:

• https://github.com/cpplint/cpplint/tree/2.0.1
• https://github.com/cpplint/cpplint/releases/tag/2.0.1

When releasing, we will:

• Merge a new pull request that only updates the version number and updates CHANGELOG.rst.
• Go to https://github.com/cpplint/cpplint/releases/new
• Put in the NEW version number.
• Click the Generate release notes button
• Click the Save draft button and ask other maintainers to review.
• Ship it and check https://pypi.org/project/cpplint after a few minutes.

Updating the version should only be done in the release process, not before.

In my opinion, it is worse. It can falsely confuse users (and support agents) into thinking the trunk software is on the latest stable release, and the only "benefit" of only updating the version on release is not needing to debate the version number. Nearly every major project I know bumps the version number immediately after release. I also do not see different PRs making different guesses on the version number, and it bumps the semver feature part as I feel like we should have at least e.g. #64 in the next release. Maybe we should just put a temporary version number (e.g. 2.0.1-next for right after releasing 2.0.1) in cpplint.py and leave the new CHANGELOG header as "TBA"? I like your blank lines idea, though.

https://github.com/pydantic/pydantic/blob/04fd6395c7165232785992a6ad0e817e9db6e590/pydantic/version.py#L9 Same as the recent release made four days ago.

Preparing for tomorrow’s release of Celery celery/celery#9660