Offering to co-maintain Recurring Events

I was actually hoping to find a new co-maintainer and I have to say the effort you've been putting in has been really appreciated. I've just been unable to dedicate as much time as I would like to the project recently.

So, without further ado. Welcome to the maintainer group and thank you for all you do. If you ever want to sync up on issues or ideas feel free to find me on Drupal slack @owenbush

Thanks so much! Happy to be part of the team :)

I just want to thank pfrenssen for working on the module. It's very appreciated. I am trying to find some time to contribute to testing updates more often.

For me, because this module is very central to my clients' websites, I would just like to make sure all changes are thoroughly tested before getting merged. If any changes involve major departures from current functionality, perhaps we can always make sure that these changes are optional and require site admins to opt in rather than being enabled immediately?

I fully agree with this. Testing is super important. I try to always provide a unit test for every bug fix or feature request I work on.

For functional changes, I think it is a good idea that changes that impact existing workflows should be opt-in, but I suppose this doesn't extend to new features that don't impact (non-admin) end users?

Work has started on a 3.x branch that will target newer platforms (Drupal 11 + PHP 8.3). Maybe we should reserve any feature requests for 3.x and keep 2.x stable until the EOL of Drupal 10?

I agree with all you said and really happy to see the work you're doing. For our sites, as an example, we had some important features that broke when a recent update to the module changed the registration service to no longer be aware of the current event series and instance by default. We had to roll back and stay at a previous version and change our custom code to work with the new version of the module. I mean this only as an example of how some backend updates can still have an impact on the site. In this case, I believe the change would still pass all tests, but still have an impact on how sites were using the module. So I would advocate for more than just unit testing but human testing by as many participating sites as possible (which I guess is ideal for any module). But maybe we can get a bit more community input before moving big changes into the main releases?

Maybe a good solution would be that if we plan a new release that we announce it in an issue and allow for a 1 month "trial period" before actually making the release? Then the users have time to test and report issues ahead of the release.

I am sorry for the inconvenience caused. Unfortunately it is hard to predict the impact that certain changes can have on end users, especially relating to custom code that might be written. In any case it looks like you followed the right process: if a new release causes an unexpected issue, the best way is to temporarily pin the previous (working) release and report issues that were found so they can be fixed, and can be included in the next release.

These are very interesting and important points which benefit from a wider discussion, so I went ahead and made an issue to discuss the project governance. We can collect feedback there: 📌 Discuss the project governance Active .

Amazing... really excited to help make this module grow and become even more awesome.

Automatically closed - issue fixed for 2 weeks with no activity.