there would be a lot, but these would be build releases - each project is slightly different. It can also be done when merged to the default branch this will reduce the releases because they would have had to be reviewed first and merged first

from hacktoberfest-practice.

It's great having you contribute to this project

If you would like to continue contributing to open source and would like to do it with an awesome inclusive community, you should join our Discord chat and our GitHub Organisation - we help and encourage each other to contribute to open source little and often 🤓 . Any questions let us know.

from hacktoberfest-practice.

Stale issue message

from hacktoberfest-practice.

We still want this Stalebot 🤓

from hacktoberfest-practice.

Wait, I am not sure I understand. You are proposing a release every time a PR is merged? That would be so many releases. Why would we need that?

Perhaps, I don't completely understand.

from hacktoberfest-practice.

@adityaraute it is good to have build releases, for example increment the X on the release version 0.0.X each time

from hacktoberfest-practice.

Every time we push a commit?

from hacktoberfest-practice.

ideally each commit push should be deployable - in the perfect situation, which is not always the case. I think when people realise a potential release is created they try to push better commits or group commits together and do not push then until ready - so really it is on each push not necessarily each commit

from hacktoberfest-practice.

I did mean each push, yes. That would be too many releases, though. Wouldn't it?

from hacktoberfest-practice.

Stale issue message

from hacktoberfest-practice.

We not doing this then?

from hacktoberfest-practice.