I'd like to define a clear release cycle like golang, for example.
This is a proposal to make it possible for many contributors to become aware of the schedule based on the release cycle and to promote smooth development.
In addition, by reflecting this proposal, it also makes it easier to manage many tickets.

This started in #1443 with #1443 (comment) and I've been meaning to reply so here goes

Frequently releasing the patch version is not good for me.

I understand you @namusyaka and it is good that you tell us this. Hopefully we can find ways to make it better. I will try to express my ideas.

When releasing, we'll always need to update changelog and write blog posts.

I agree that the changelog needs to be update when a new version is released. One idea to make it easier for you as the maintainer could be that we ask contributors update the changelog in their pull requests.

Re: blog posts, personally, I don't expect a blog post with every release (I don't expect any blog posts, I consider them a bonus). So just skip blog posts is another idea. :)

At least I think that it's better to develop along milestones as much as possible unless a very critical problem is found. On the other hand, it isn't always best to release on milestone street. That leads to stagnation of development.

I think you are right about stagnation. Currently, the v2.0.4 milestone is at 27% with 24 open issues. To be honest, if all of these are required to be tackled in some way before 2.0.4 can be released, I wouldn't expect 2.0.4 ever to be released. Sorry if this sounds harsh.

I think it would be different if the milestone for 2.0.4 had fewer issues you wanted to be solved before releasing it. Then I think it would be realistic that the people asking for a new version to be released, would consider contributing to get the new release out.

So it may be a good idea to decide rules like releasing it once a half year, or once every few months like golang. What do you think?

Sure, I think it would be good to know when the next release will happen. However, I think projects that have adopted this model is projects that have much more active development (more contributors, bigger community) than Sinatra.

I think we have to realize that Sinatra isn't a very active project in terms of new development, and I think Sinatra needs to find a way to engage with those few that are interested in contributing. On this topic I think it is important to resolve the activesupport situation (#1448) as I think it is something that is turning long-time Sinatra users away.

Hello @dentarg, thank you so much for your comment. I'm pleasure to see your participate.

I agree that the changelog needs to be update when a new version is released. One idea to make it easier for you as the maintainer could be that we ask contributors update the changelog in their pull requests.

This is good. Your idea can easily be possible by adding sentense in CONTRIBUTING.md and implementing Danger for noticing about CHANGELOG.md. See also grape development iteration.

Re: blog posts, personally, I don't expect a blog post with every release (I don't expect any blog posts, I consider them a bonus). So just skip blog posts is another idea. :)

If blog post is big maintainance cost, we should consider to skip blog posts for each releases.

I think you are right about stagnation. Currently, the v2.0.4 milestone is at 27% with 24 open issues. To be honest, if all of these are required to be tackled in some way before 2.0.4 can be released, I wouldn't expect 2.0.4 ever to be released. Sorry if this sounds harsh.
I think it would be different if the milestone for 2.0.4 had fewer issues you wanted to be solved before releasing it. Then I think it would be realistic that the people asking for a new version to be released, would consider contributing to get the new release out.

We don't necessarily need to proceed with the development on the first milestone street.
The reason for putting a mark is because it has an effect to make it easier to understand to which level version it's classified.
Rather, I don't like development stagnation dragged by it.
My first comment is that patch releases shouldn't be made with the user's wish as a trigger.
I think that I can solve your problem consciousness by defining the release cycle, which is the original proposal of this issue. What do you think?

Sure, I think it would be good to know when the next release will happen. However, I think projects that have adopted this model is projects that have much more active development (more contributors, bigger community) than Sinatra.
I think we have to realize that Sinatra isn't a very active project in terms of new development, and I think Sinatra needs to find a way to engage with those few that are interested in contributing. On this topic I think it is important to resolve the activesupport situation (#1448) as I think it is something that is turning long-time Sinatra users away.

I don't believe that defining the release cycle is only useful for large scale development.
For example, if the release cycle is obvious, it's easier to share work among multiple maintainers.
Also, at the present time, sinatra is not an active community at the moment. And I don't like this situation so much.
Sinatra can also incorporate more wonderful features for v3.0. I believe that the potential demand of sinatra is still much.

I don't think that I'll be able to stay in active maintainer of sinatra forever.
Therefore, I'd like to foster development cycles that don't depend on me and to increase new committers and maintainers for improving great community and software.

Your idea can easily be possible by adding sentense in CONTRIBUTING.md and implementing Danger for noticing about CHANGELOG.md. See also grape development iteration.

I re-read the comment by @gjtorikian in #1443 and I saw that https://github.com/github-changelog-generator/github-changelog-generator was linked. This could be an alternative to nagging the contributor about writing a changelog entry.

I also liked this part

While my projects don't have the history of Sinatra, for bugfixes, after a merge into master I'll almost immediately release a patch version. If one has followed semantic versioning properly, it should be a nice improvement to every dependent user, rather than waiting weeks for a "collection" of bugfixes to go out.

I would prefer this, and if I maintained a project I would try to do it like this.

However, I am not maintaining and I think you @namusyaka a free to pick any strategy you want for maintaining Sinatra. If that is a fixed release cycle, go for it.

sinatra/sinatra.github.com#241