Start v1.8.1.1 release candidate

[cpsievert]

No description provided.

[gadenbuie]

I know this change is small, but I would like to advocate for us sticking with semantic versioning and calling this v1.8.2 instead of v1.8.1.1. In general, I think it's best to avoid these non-standard version numbers except for the (hopefully very) rare case where we need to both make an out-of-cycle hotfix and have also already moved the version number past the most logical next choice.

[cpsievert]

I think it's best to avoid these non-standard version numbers

Do you have reasoning for this beyond sticking to semantic versioning? This is a practice we've done for quite a while and I do like that the version itself indicates it's a patch release

[gadenbuie]

This is a practice we've done for quite a while and I do like that the version itself indicates it's a patch release

I mean, the version format is <major>.<minor>.<patch> so in that regard it's not really a patch release – at least not in the semantic versioning format. semver.org guidelines include pre-release and build information, but those are separated from the version number by -<pre-release> and +<build>.

I think that it's one thing to step out of semver because we're forced to push a hotfix to CRAN that we hadn't accounted for, but we should adhere to semver as much as possible. In this case, nothing is forcing us to add a non-standard version component.

[cpsievert]

I'll let @wch have final say on the version (we had both agreed that 1.8.1.1 was more appropriate)