Conversation
|
This looks much better 👌 |
| @@ -1,3 +1,3 @@ | |||
| { | |||
| ".": "6.26.1" | |||
There was a problem hiding this comment.
Ok, this looks like a better PR, but for all the work we've done and the significant dependency updates, I think this should be a minor, if not major, release after 3 years. @jdalrymple any thoughts on this? I can read through the docs again to understand how we ensure that at least 6.27 is the new version.
There was a problem hiding this comment.
One way is to merge a commit with
Release-As: 6.27.0
On the last line and it'll override the autodetection
|
Ok, maybe 7.x doesn't make sense here, but at least 6.27 does, given how long it's been since the last release and the significant dependency updates that could warrant breaking changes in a user's environment. I'm not sure, but 6.27 seems reasonable. Even looking at the commit history, it wouldn't follow a typical semantic minor bump. |
It does!! Thank you so much for noticing this. I need to look at which commit types would trigger a minor vs. major release. What is unclear here is that it's been ~3 years since a release was made! And we made some significant updates to dependencies. But it's not breaking for users because the front-end API hasn't changed, only the backend. |
feat! = major |
🤖 I have created a release beep boop
6.26.2 (2026-03-07)
🔥 Bug Fixes
📚 Documentation
⚙️ Chores
package-lock.json(#434) (5de78d9)⌨️ Code Refactoring
🧪 Testing
add-contributors-listtests (#396) (84ac3ed)🛠️ Build System
This PR was generated with Release Please. See documentation.