Define Ceedling's Release Cadence and Process

[mvandervoord]

I'm starting this thread so other members of the community can voice their opinions on this topic. I have some opinions on this, but I promise to be open minded and listen to everyone's thoughts. I recognize that this project was built by many of us, and I'd like us to decide how it should go.

Conversation Starters:

Cadence

I have always dreamed of quarterly releases. I don't know if it's possible for a project that is completely run by volunteers? Attempts in the past haven't been very fruitful... but I've also made the mistake of basically making it a personal goal instead of a community goal.

I'm going to propose a 6-month release schedule where we have particular milestones... something like this:

• Jan / July - We decide a "focus" for the next release
• May / Nov - Stop accepting new features to this release. Still accept reasonable bugfixes
• Jun / Dec - Release

Process

• We need to find a happy medium between reliability and overhead. We are volunteers, but we are volunteers that care about quality (or we wouldn't be on this project).
• We need to do better at defining overall direction.
• We need to do better at self-validation, documentation, etc.

[Letme]

My personal opinion is that for smaller open source projects, having a fixed cadence for a release is bad. With all the automated releasing (and testing - this is important for not breaking existing functionality) we can basically make a release after each pull request (a bit excessive, but you get the point). We can plan Pull requests (not issues) that should be completed before next release and in that way give some cadence to the project.

So, my proposal is that we follow a few steps, which will limit time for developers and can be done by non-Ruby savvy people as well. Bullet point 4 and probably 5 need to be done by Ruby savvy developer and if those pull requests or issues are marked already with that label, it is much easier to filter and start on the job:

• Cooperate on issues to get a concise limited scope of the feature to be implemented. A default Issue template here is a key, which gets the version information, command ran information, project.yml configuration, etc. The helper point here would be that ceedling would be able to pump out this information with command (think of --verbosity on steroids into a file instead of terminal).
• Use labels on issues to mark the progress for the community of how far along the issue is. That means once it is identified as bug or feature, put a label on it as such. Additionally, we want labels for documentation only (docs label is existing), ruby (to know the skillset needed) and potentially infrastructure.
• Apply also labels to the pull requests, but also assign pull requests to Milestones. That way we can easily group the features into a release. It also means we create milestones for next feature version (1.1.0), for next bugfix version (1.0.1 - which can be added to 1.1.0 if that comes sooner) and backwards compatibility breaking potential with next major version (2.0.0)
• Now we have "project management" part settled, the developers come in. Each pull request requires certain quality, and pull request template is a way to inform new contributors of what the minimum entry level should be. That can be a nice checklist, and at the beginning information that we can help them achieve the quality if they ask - that means that developers can start small, with just working example, and then we can take the pull request over and add quality when needed. The beauty of this is that they retain original contributions, even if your changes afterward significantly change the codebase (even if they have 0 lines in the final code).
• After pull requests have all checkmarks done (here we should enforce 1 review required setting) then the pull request can get merged. This can be a single person, but the reviewer will already add some quality to this
• So release of this new bug/feature can be done after milestone is complete, or when some inactivity time has passed on the linked pull requests.

This works on quite few of other small projects where you have 1-5 active developers, but peer reviews also help increase other people's quality levels, although with beginners they might take more time than just taking over the Pull request and complete it, to begin with.

[jmrubillon]

I like @Letme's suggestions. Not a formal cadence at a fixed pace but a responsive one to fix bugs and a slower one to add new features. As @mvandervoord pointed out people are volunteers and adding arbitrary deadlines may only discourage developer from contributing.