Maintenance release

[kevinpapst]

Thanks for building Yasumi 👍

I am writing to ask is about the release strategy used for it, as the last release 2.11.0 was 6 months ago and 45 commits:
https://github.com/azuyalabs/yasumi/releases/tag/2.11.0

Many of those commits are not just quality of life improvements or new providers, but also quite a few bugfixes.

I assume there is a reason why you do not simply click on "create release":
Can I support you somehow so the community can benefit from the new code?
E.g. by adding a release drafter workflow to always have a release preview with an automated changelog (simplifies the process, you just need to click "publish release")?

Yasumi is used in business context and getting those changes is likely important to many folks besides myself.
The only solution we have is pointing to main in composer.json, which has way too many downsides and same goes for pinning a certain commit.

The README contains no information about your release workflow and the history of releases is wildly mixed, so there is no indication when we could expect a new release.

To come to an end: I am not only asking for a new release here, but also offering help if needed.

[stelgenhof]

Hi, and thanks for the kind words and for offering to help.

You're right that there hasn't been a release since 2.11.0, and that quite a few fixes and improvements have accumulated on develop since then.

One thing I'd like to clarify is that releases aren't being held back because the process is manual or because I simply haven't gotten around to creating a GitHub release. "Yasumi" does have an automated release process, although that process is performed outside of GitHub and isn't currently documented in the repository.

The release approach has evolved over the lifetime of the project. In the past, I would create a release once a useful set of changes had accumulated. More recently, I've moved towards a time-based release cadence, with releases generally planned twice a year, around March and September. I realize that this isn't currently documented anywhere in the project, which can understandably make the release history look somewhat arbitrary.

A release also involves more than publishing a new GitHub release. Next to making sure each release is stable and well-tested,I maintain the "Yasumi" documentation site separately, and I want the documentation and released version to remain aligned. The release process therefore includes coordinating those updates as well.

So while I appreciate the suggestion of adding a release drafter, that's not something I currently need help with—the release process itself is already automated. What I should do is document the release cadence and the general release process so that users have a clearer expectation of when and how releases are made.

The twice-yearly cadence isn't intended to prevent an additional release when there's a particularly important bug fix, rule corrections or compatibility issue that shouldn't wait; it's simply the cadence I'm currently using for normal releases.

Thanks again for raising this and for offering to help.

[stelgenhof]

Releases of this project have historically been made whenever a useful set of changes had accumulated. Over time, this made the release history look somewhat arbitrary. More recently, I (silently) shifted to a schedule of two releases per year, around March and September, but that schedule was never documented anywhere in the project.

To make it easier for users to understand when the next release is expected, a Release Policy has now been added to the project. This policy defines:

• a twice-yearly release cycle, with scheduled minor releases in March and September;
• SemVer versioning, with tags carrying no v prefix (e.g. 2.11.0);
• patch releases that ship as soon as possible — holiday legislation changes, rule corrections, and compatibility fixes do not wait for the scheduled release cycle;
• what belongs in a scheduled release, and the quality gates that every release must pass.

Hopefully, this makes the release cadence a little more predictable and gives users a better idea of when to expect the next release.

[kevinpapst]

Thanks for sharing that info, it is good to have a timeline.

As you plan the next release soon: let me know if you need any help with that!

---

Are you open for discussions about the release policy?

I understand this is mainly a hobby project and it is your project and it's up to you to make the rules.

But I'd like to share my experience with my projects to maybe shift your perspective: as soon as an fully automated release process is in place, it starts being fun to release often. The less often you release, the "scarier" it feels. In my projects the only manual work is to a) click edit and then b) click publish on the draft release, which was created and kept up-to-date by GH actions. The CHANGELOG and everything else can be updated automatically as well.

And you already have tests and quality tools in place, nothing gets merged before it is releasable.

Why holding it back? It's not wine that might get better over time. IMO your argument is correct, but the conclusion is wrong:

Because downstream systems and projects rely on Yasumi for critical processes such as payroll, payment scheduling and other business logic, predictability and correctness are prioritized over release speed.

I have real 500 prod bugs since a very long time and the only way to "fix" them, was to implement a second public holiday provider that fetches the data from Google calendars. Your library is stable in the way that it can't be reliably used in certain environments, so yes the stability exists, but the wrong way around. I have Ukrainian users with 500 errors and Australian users complaining because their public holidays are wrong - both issues already fixed in develop.

Please do not understand that as "me demanding" anything from you, I am just trying to explain the situation of a downstream project: a 6 month release cycle pretty much forces me to either use develop or find other workarounds - and both solutions are riskier than multiple small releases, which only include fully tested changes. This is especially true for bugfixes, but also for updated public holidays or new providers.

Consider this: you publish a release and we find a bug within days. Is it really better to have to wait for 6 more months for a fix? Or: I sent you a PR that is merged and released within a few days (taking just a few minutes of your time for the review and two clicks for the release)? Also: all major libraries that most of us use (e.g. Symfony, Doctrine) are even deeper integrated into business workflows and they are released every few weeks.

That's why I asked if I can help e.g. with an improved release workflows, that takes away any manual work that you currently spent with it. Releasing should be possible within minutes at any time without manual steps.

If it is not about the workflows, but your opinion that a "twice a year release cycle" is, I will promise to shut up. But I will not let that slip without at least offering my help.

---

Or is all of my input above basically outdated, because of this new rule:

Patch releases contain bug fixes and updated holiday data only. They never introduce breaking API changes.

Because I haven't seen such a patch release yet. Is that a new process that you plan to introduce soon after the September release?