Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

So many releases #1360

Open
ghost opened this issue Mar 24, 2024 · 3 comments
Open

So many releases #1360

ghost opened this issue Mar 24, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@ghost
Copy link

ghost commented Mar 24, 2024

Describe the bug
Yes, I consider this a bug. Why are you doing so many releases? What justifies the lack of a cadence of releases?
Can I consider this amount of releases as being considered "spam"?

In practical terms, what makes you think that we need this amount of releases?
Do you think your project is so unstable like that, that it so urgent to release those fixes?

Do you think that we have the available time to be reading every changelog, twice a day or more, and be updating every time, checking if things are broken and like that? There were 3 releases today.

Don't you agree that it would be easier for our time and also yours if things were to be released in a more reasonable cadence?
Of course that projects may depend on this speed of releases: that is what alpha or beta channels are for. npm allows to adjust this too in package.json, and you can easily maintain these 2 channels of releases in parallel.

You could very easily release one version per week and that would still be more frequent than 99% of projects out there! It would be totally acceptable for the scope of happy-dom, I suppose.

happy-dom has been releasing a lot of fixes for features that have been developed in the previous day. That makes me think that you rush sometimes, and the time spent producing one fix could have been better spent actually testing what has been developed more accurately in first place.

Don't get me wrong in the tone of the words. I just want to make it clear that there are drawbacks in your current release cadence, as much as there are benefits. In no way I am writing in an aggressive manner.
I appreciate your project very much and of course I appreciate the patch fixes that are being released to make happy-dom better. But updating a dependency, in some contexts, needs to be done so carefully, that it takes time, and we can't ignore the pending update. And to be frank, even, it is annoying to update any project at all, so imagine having the task of updating this one a lot of times in a week (There were 20 releases in 1 week). This is not even easier to follow as it may seem.

Maybe you don't need to follow milestones if the scope of this project is small, but milestones would still be appreciated, in order for you to give a better focus for each release. To group updates following a common reason. And then the changelog themselves are going to be more focused, easier to reason about..

I want to emphasize that we appreciate very much your dedication and your project. The feedback is that your efforts could be even better if you could review the frequency of releases, please.

Thank you.

Obs: I don't want this comment to affect your motivation. I just want you to improve your work. And I'm sure feedback when considered will only improve things.

@ghost ghost added the bug Something isn't working label Mar 24, 2024
@capricorn86
Copy link
Owner

Happy DOM uses a Rolling Release cycle and Github Flow.

Development done for Happy DOM is implemented Test-driven. That means that each bugfix or feature is covered by automated tests, which is implemented together with the code on a branch (integration, e2e or unit tests). If needed, manual tests are also done on the branch, but an automated test will always be created if something is found. Nothing goes into Happy DOM without test coverage and there are currently about 3200 automated tests.

When the code is ready, a pull request is created. If the pull request passes the builds and review, it will be merged. Once merged, a release is done automatically.

It is possible to create a queue and release less often, but then the community will have to wait for fixes that could have been released directly, as they are ready to be shipped.

Why are you monitoring each release if you are only interested in updating each week? Why not just setup a CRON job that updates Happy DOM each week or something similar if this is what you are after?

If this is a problem for more people in the community, I'm definitely open to create such a queue. Then I hope these people will answer in this thread, because it is otherwise hard to know if this really is a problem or not for the majority of the community.

@sureshjoshi
Copy link

If this is a problem for more people in the community, I'm definitely open to create such a queue. Then I hope these people will answer in this thread, because it is otherwise hard to know if this really is a problem or not for the majority of the community.

It's your project (awesome project BTW), release at whatever cadence is the most maintainable for you - that's the only thing that matters here.

Package consumers can change their notifications settings however they want right from Github - that's a complete non-issue.

Screenshot 2024-03-26 at 16 39 53

Personally, I can't fathom why someone would want access to fewer, less frequent releases for something equally tested. 🤯

@capricorn86
Copy link
Owner

Thank you @sureshjoshi! It means a lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants