Closed manatarms closed 7 years ago
We really, really need this.
For example, cf-component-heading says it's a breaking change but nothing seems to be broken.
I make breaking changes whenever the API changes to communicate to consumers of this library that their code might not work any more and I think I did it that way this time around I think. Breaking change doesn't mean anything is broken but is more that there is a possibility of something breaking when you update.
In any case I'm down for this. lerna
has a conventional commits flag that allows us to generate a CHANGELOG automatically that I think would help a lot. I also determines the version bumps from those commits so I think the benefits are great.
I was trying to say that I had no idea if something could break or not. I'm don't deny that Fela stuff should definitely a breaking change but it would just be nice to see what was changed. :)
True, I've been going into cf-ui and running the following to get a diff of the changes.
git diff cf-component-button@2.1.2..cf-component-button@4.1.5 -- packages/cf-component-button
It's not perfect but it helps. In any case I think the conventional commits would be super helpful. Takes away a lot of pain without much work.
I'll add it to the weekly meetings if someone minds if we enforce this.
I've looked at most button usage. Trying to get LB and RL to work with dev so I check out those as well.
Just throwing out an idea since we're all systems go on Fela migrations. Can we start adding CHANGELOG files to individual packages when they're published. Simple stuff like what was upgraded and why it could break.
I've been trying to migrate a few things in www-next but not knowing what could have broken is a big pain. I'm just guessing and hoping that nothing has broken. For example,
cf-component-heading
says it's a breaking change but nothing seems to be broken. (Which scares me).What do you'll think?