auto-merge and semantic release about eslint-find-rules HOT 13 CLOSED

So we are good to get rid of semantic-release?

from eslint-find-rules.

Sure, but those few (I guess it's the three of us? have to check) should somehow at least have agreed on a common scenario (e.g. "main publisher") and how to generally react when that will not work ... like, avoid having two users trying to publish a bugfix version at the same time (although I have to admit this will probably be a very rare scenario)... but maybe I'm just overcomplicating here. Let's just try it.

from eslint-find-rules.

@ta2edchimp you already have the publish rights. I added @ljharb too.

I will raise a PR to take out semantic-release and add standard-version to the workflow (needs to be manually executed).

Closing this ticket as we are good on the discussed approach. Please feel free to open the ticket should we need any further discussion.

from eslint-find-rules.

This is why I stated, "Please don't approve it via GitHub means, otherwise, the PR will get merged".

But looks like GitHub will not automatically merge the PR. I would raise a simple PR with README updates, as a follow up and see how it behaves.

from eslint-find-rules.

Besides "spamming" with updates when lots of PRs would get merged within a short period of time

My 💵 0.02.
Not sure if I would call it "spamming". semantic-release will not perform any release if it does not find the word "fix" or "feat" in the commit message. So we can control the release. Having said so, at times there could be multiple fixes/features across PRs, at that time it would release multiple version. In a way that's not bad, I suppose.

from eslint-find-rules.

Re: semantic release

Yeah, that's why I put it in quotation marks; because on the one hand I see how it semantically makes perfect sense to have a version released for each and every merged fix and feat, but on the other hand may feel (to some) as if it would add a lot of noise to the release history.

To sum it up:
I see that there's the need to have more control over what gets released when, in what order and together with what other features and fixes in large projects, like ESLint for example (although I'm expecting them to also make use of an automated release workflow, I guess no one's npm publishing every version manually from his machine).
But I think that semantically releasing new versions as we do it for this project (and other projects of its size) on merging into master with successfully running tests, is perfectly fine. 👌

from eslint-find-rules.

My concern about semantic-release is that it puts too much trust in PR authors/mergers. I definitely think each PR should explicitly state the semver level that applies to it - but the actual publisher should manually audit every line of code that is going into the publish. PRs can be reverted, but npm versions can't be unpublished (after 24 hours or a dep).

Manually creating and tagging a release takes me 5-10 minutes on each of my published projects (50-100). The tradeoff for that time is that I avoid the situation where someone clicks "merge" - something that doesn't require manual command line verification or testing - and all of a sudden people's builds are broken.

semantic-release prioritizes developer time over consumer time, and I think that is always a hostile decision. Things SHOULD take more time for the publisher/developer, if it means that the consumer is less likely to break.

from eslint-find-rules.

Maybe we can use https://github.com/conventional-changelog/standard-version to make manual release less tedious.

from eslint-find-rules.

@sarbbottam Looks like a good alternative.

@ljharb Well, thanks for the reasonable explanation!
How do you usually manage responsibilities to publish new versions?
(Edit: regarding modules where you're not the only collaborator with publish rights, of course)

from eslint-find-rules.

@ta2edchimp usually I make a checklist, which includes waiting for travis to pass on the pushed tag before trying to publish; and then sometimes i might mandate a 👍 on the tagged commit from another collab before being able to publish. whatever works for the team.

from eslint-find-rules.

Looks good to me.

One last question: How do we determine who releases a new version? Simply let @sarbbottam do it generally and decide otherwise (e.g. within the context of a PR), should he be unavailable / absent (idk, on vacation or sth.) for some time?

from eslint-find-rules.

That seems fine. Typically the users who have publish rights are fewer than those who have commit rights anyways.

from eslint-find-rules.

I'm a bit confused: We closed this ticket, but the automatic release using semantic-release still is invoked on Travis, it just errors out upon execution (see here).

from eslint-find-rules.