melos icon indicating copy to clipboard operation
melos copied to clipboard

chores are not considered by melos version

Open shyndman opened this issue 3 years ago • 4 comments

Hey

I'm in a situation where I upgraded a dependency across my packages (graphql 5.0.0-beta.2 -> graphql 5.0.0), and marked it a chore. The upgrade is the sole commit on top of the previous version.

It appears that melos version does not consider the chore versionable. Shouldn't it be?

Screen Shot 2021-06-11 at 2 18 22 AM

And if not, maybe logging something like "X commits were not versionable", or something to that effect? I would have found that helpful.

shyndman avatar Jun 11 '21 06:06 shyndman

Based on the conventional commits spec chore commits alone don't trigger a version since it's usually used for non-production code changes, e.g. adding a build script. They do however appear in change logs if there's other commits that did trigger a version bump.

I'd be open to have logging as part of melos version that shows all the commits being picked up, chore and non-chore. Option B would be add a config to allow chore to be versionable

Salakar avatar Jun 11 '21 09:06 Salakar

Based on the conventional commits spec chore commits alone don't trigger a version since it's usually used for non-production code changes, e.g. adding a build script. They do however appear in change logs if there's other commits that did trigger a version bump.

Ahhh, got it.

I'd be open to have logging as part of melos version that shows all the commits being picked up, chore and non-chore. Option B would be add a config to allow chore to be versionable

I think that option B might make sense. It's nice to be prescriptive, but escape hatches are good too.

I think my ideal would be to understand what was happening through command output, and be given a clear option on how to force a version if I wish to.

Ultimately I rewrote history. Not a big deal, but I also had to figure it out first.

shyndman avatar Jun 11 '21 20:06 shyndman

Relevant TODO (since I don't think this should exist in the conventional commit package): https://github.com/invertase/melos/blob/master/packages/conventional_commit/lib/conventional_commit.dart#L214-L228

I also envisioned that you could configure the specific types supported in the conventional commits package and which ones are versionable (outside of conventional commits package).

My 2 cents :P

Salakar avatar Jun 14 '21 12:06 Salakar

Relevant TODO (since I don't think this should exist in the conventional commit package): https://github.com/invertase/melos/blob/master/packages/conventional_commit/lib/conventional_commit.dart#L214-L228

Gotcha

I also envisioned that you could configure the specific types supported in the conventional commits package and which ones are versionable (outside of conventional commits package).

Agreed.

shyndman avatar Jun 14 '21 15:06 shyndman