Closed aminya closed 4 years ago
I think commit history bloat is a good tradeoff to be able to see when a specific dependency breaks something.
If we do something like bump_deps.yml we need to make sure tests don't have to be run manually and we can exclude certain updates if we need to because it breaks something.
For future updates, I am totally OK with adding a test step. However, I am also interested in squashing the commits that are already on the master branch.
I think the dependency upgrades should be tracked, but when all the updates are going to be landed on a single release that users check, there is no point in having separate commits.
Also, minor updates like @types/
packages are not going to affect the release, so squashing those will not have any effect.
If the commit history is cleaner, we can track the "actual code changes" better.
If the commit history is cleaner, we can track the "actual code changes" better
I think there are already better ways of tracking actual code changes than looking at commit history, but I am ok with squashing commits before this is released.
I was just given permission for atom-languageclient
and would like to get v1.0.0 released today. Is there anything you would like to do to the code before that?
Great news! Can I squash the dependent bot commits?
We also need to rename the package back to atom-languageclient.
sounds good :+1:
I renamed the repository. Could you make a PR renaming the package itself?
I created #88 to rename the package. After you squash the commits I'll publish v1.0.0
Squashing done! Closing this.
There are many numbers of commits on the master that just bump a "@types/" packages that make following the changes very hard. These have created a commit history bloat.
Can we get these squashed?