🦋 Changeset detected

Latest commit: 0976d7b

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 87.28%. Comparing base (070f531) to head (0976d7b).
⚠️ Report is 3 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2128      +/-   ##
==========================================
+ Coverage   86.18%   87.28%   +1.09%     
==========================================
  Files          71       71              
  Lines        2585     2548      -37     
  Branches      703      681      -22     
==========================================
- Hits         2228     2224       -4     
+ Misses        330      300      -30     
+ Partials       27       24       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

I think it's fine keeping it as tag though. We don't need the commands to be related to npm, so tag being "tagged via git" is somewhat ok to me. So I think it's not worth breaking or deprecating for now, until we have some plans to create a different changeset tag command & behaviour.

I'm fine with keeping the name as-is - but I recall some users reporting in the past that changeset tag was misleading to them because it was different from what changeset publish calls a tag

I think after reviewing changesets/action#680, I could kinda see the benefit of this. But if we're to land this, the changeset tag command should still work but log a deprecation warning instead.

I think after reviewing changesets/action#680, I could kinda see the benefit of this. But if we're to land this, the changeset tag command should still work but log a deprecation warning instead.

I mean to be fair, we also rename some action inputs in that major bump without deprecation, so why not do it like that here?

Not to say, I do not like a slow migration. I can see that in the action two inputs for one setting at the same time are confusing, so it makes sense there. But theoretically we could do the same error with a "got renamed" message here as well...

I don't mind making the old changeset tag work with a deprecation warning - given we don't really have any other plans for changeset tag.

I pushed out a commit to that effect

I mean to be fair, we also rename some action inputs in that major bump without deprecation, so why not do it like that here?

Not to say, I do not like a slow migration. I can see that in the action two inputs for one setting at the same time are confusing, so it makes sense there. But theoretically we could do the same error with a "got renamed" message here as well...

For me the core commands here feel more important and general, where it can be used for many cases like setting up a custom bash script, child process, custom workflows etc that it's intricate. If it suddenly doesn't work, it'd have a larger impact compared to the breaking changes in the action.

But you're right, initially we're conservative with breaking changes, making the major mostly clean-up focused, but we've recently been making quite some breaking stuff already. But given compat support is only a few lines, I think we can swallow the cost for now.