With my open source work, I've historically taken an approach which relies more on integration testing than unit testing, but with some of my newer projects, I've tried adopting principles from $paidwork and applying them to my free software.
This is a quick run-down of how I'm structuring my test suite in newer projects. It's likely that many of my existing projects will never adopt this structure, but some may.
Consider the following fairly simple class, which creates a lookup object for month names:
package Local::MonthList {
use experimental ="color:#333;backgr…
This is a variant of SemVer which mostly meets all its rules, except for releases prior to 0.2.0, where we bend them slightly.
It is my intention to use this versioning system for all open source software I develop from 1 January 2023 onwards. Existing open source projects I manage will adopt this scheme from their next release onwards. (Type::Tiny already somewhat does.)
Eagle-eyed watchers of CPAN may have noticed that I've recently been releasing Type::Tiny development releases with version numbers 1.999_XYZ.
Type::Tiny v2 is intended to be compatible with Type::Tiny v1. If you've used Type::Tiny v1, you shouldn't need to change any code, but Type::Tiny v2 has a few new features which may make your code simpler, more maintainable, and more readable if you adopt them.