Broken SemVer

[ai]

Should Add --color and --no-color flag support be in 2.1 (as a new feature of color auto-detection) or in 3.0 (as breaking changes of color support)?

[kibertoad]

I can see the rationale behind both approaches; very technically it is a breaking change, but pragmatically it is not very realistic for someone to force no-colour and actually desire colour somewhere, so 2.1.0 sounds like a more sensible approach. Wonder if it's still realistic to rollback the change and remove it from 2.0.x branch, considering that there are projects relying on latest release :(.
@jorgebucaran Would you consider embracing mandatory PR approach for this project so that similar questions are discussed in timely fashion?

[kibertoad]

Also I agree that SemVer is important, should we try following it from now on?

[jorgebucaran]

#77 introduced no API changes, so I'd argue that either a minor or a patch are reasonable. On the other hand, new features are traditionally introduced in minor releases, so I agree that 2.1.0 would have been nicer all things considered.

👍 for a PR-based approach whenever we want to make incompatible API changes, add new features in a backward-compatible manner, or fix bugs. Optional for non-breaking internal changes (code refactoring) or documentation changes.

How does that sound?

[kibertoad]

Looks good to me. Can I also join the maintainer bandwagon, btw?

[jorgebucaran]

Certainly! 👌

[kibertoad]

@ai Would you consider joining as a maintainer and helping enforce semver among other things?

[ai]

@kibertoad I can’t work with him because of his impulsive actions like blocking Babel PR for every color library or DCMA takedown of oh-my-fish

[kibertoad]

@ai Wouldn't having you on a team make it easier to prevent any future impulsive actions?

[ai]

@kibertoad how it could prevent him from using aggressive actions again?

[kibertoad]

@ai It was a result of emotional decision-making in the heat of the moment. Having a network of fellow devs to talk things through generally makes such things way less likely to occur. Jorge himself is not proud of what happened back then and he did grow as a person considerably.

[ai]

@kibertoad Babel PR block shows that we didn’t grow. He is still using emotional decision-making.

The network of fellow didn’t help him in the current case. Any in this network can be attacked by him again on any conflict with him.

[kibertoad]

@ai I don't believe there was a network in place to have this conversation. He was a solo dev on the library and was calling all the shots on the spot, and forking felt like a personal attack at the time. Definitely a healthier discussion could have happened, but no way to fix that back retroactively.
What do anyone win from continuing feuding? Can't we at least try to resolve our differences? Jorge is offering to adopt PR policy and invite you as a maintainer in good faith.

[ai]

@kibertoad there is no big rational reasons to use libraries like nanocolors or colorette. They are most an image of optimization.

This drama poisoned nanocolors and colorette brands. They both can’t be used as image anymore.

Having a network of maintainers will not help. He can remove you from collaborator in any moment of conflict (as it happened before).

The only way for now is to switch to another color library which has less aggressive maintainer. I am switching to picocolors (also it faster and has even smaller npm package). I recommend this switch for you too and avoid any work with him (I was warned of working with him when I first added colorette to postcss, but I ignored it; you can be on my place in next years).

[kibertoad]

@ai I don't believe in burning bridges. I believe in healing and growth. Having heard Jorge's side of the story, I trust and respect him and willing to give him a benefit of doubt.
I'm sad that you feel the way you do, but should you ever change your mind, you would be more than welcome to join at any point in the future.