How to resolve ambiguity between feat/fix types? #162

New Issue

GiteaMirror · 2026-02-17T11:50:34-06:00

GiteaMirror commented

2026-02-17 11:50:34 -06:00

Originally created by @brupelo on GitHub (Dec 16, 2022).

Originally assigned to: @bcoe on GitHub.

Hi guys,

We're trying to follow the v1.0.0 specs, specially the part that talks about semver.

There is one case which it's very tricky to know whether we should use feat or fix. Let me put you a trivial example:

Let's say you've created a simple react package that's exposing some reusable components to the client:

You create a new component:

widget_foo.jsx

import React, { useState } from "react";
import PropTypes from "prop-types";


function WidgetFoo(props) {
  const { className, ...rest } = props;
  
  return (
    <span className={className}>
      I'm component {rest.arg1}
    </span>
  );
}

WidgetFoo.propTypes = {
  arg1: PropTypes.string,
};
WidgetFoo.defaultProps = {
  arg1: "foo"
};

export default WidgetFoo;

and you exposing this widget on the public api of your bundle... obviously, in this case you'd create a feat type commit, so far so good

Now let's say you decide to change the rendering by updating to

  return (
    <span className={className}>
      I'm fancy component {rest.arg1}
    </span>
  );

For the sake of simplicity, let's say the old behaviour wasn't following the existing requirements therefore we could catalogue this one
as a fix commit (not so obvious choice)

What happens when you're extending the public interface without introducing any breaking change? ie:

import React, { useState } from "react";
import PropTypes from "prop-types";


function Foo(props) {
  const { className, ...rest } = props;
  
  return (
    <span className={className}>
      I'm fancy component {rest.arg1} but I could become {rest.arg2} eventually...
    </span>
  );
}

WidgetArrows.propTypes = {
  arg1: PropTypes.string,
  arg2: PropTypes.string
};
WidgetArrows.defaultProps = {
  arg1: "foo",
  arg2: "bar"
};

export default WidgetArrows;

Which type of commit should this one become?

Or even better, what happens when you change the style of that component without modifying the public interface? I'm aware you're suggesting style in the specs... but that type won't modify semver. Even though, these sort of changes are relevant to the clients and they need to be aware of new package versions when these sort of "improvements"/"enhacements" of existing features happen.

Shouldn't the specs resolve this sort of ambiguity somehow? Is this a feat or a fix? Is it maybe other type that should also modify semver? At the end of the day semver should be driven mostly by public API pinned to customers/clients. But visual modifications, visual enhacements or feature updates will have obviously impact on customers so it should be clear which type to use and how that'd should affect semver.

At the end of the day new versions means some existing customers will spend money updating their products against your libraries, so deciding if they want to spend the time on a patch or a minor update definitely it's a big deal.

Thanks in advance!

Originally created by @brupelo on GitHub (Dec 16, 2022). Originally assigned to: @bcoe on GitHub. Hi guys, We're trying to follow the v1.0.0 specs, specially the part that talks about [semver](https://www.conventionalcommits.org/en/v1.0.0/#how-does-this-relate-to-semver). There is one case which it's very tricky to know whether we should use feat or fix. Let me put you a trivial example: Let's say you've created a simple react package that's exposing some reusable components to the client: 1) You create a new component: **widget_foo.jsx** ``` import React, { useState } from "react"; import PropTypes from "prop-types"; function WidgetFoo(props) { const { className, ...rest } = props; return ( I'm component {rest.arg1} ); } WidgetFoo.propTypes = { arg1: PropTypes.string, }; WidgetFoo.defaultProps = { arg1: "foo" }; export default WidgetFoo; ``` and you exposing this widget on the public api of your bundle... obviously, in this case you'd create a `feat` type commit, so far so good 2) Now let's say you decide to change the rendering by updating to ``` return ( I'm fancy component {rest.arg1} ); ``` For the sake of simplicity, let's say the old behaviour wasn't following the existing requirements therefore we could catalogue this one as a `fix` commit (not so obvious choice) 3) What happens when you're extending the public interface without introducing any breaking change? ie: ``` import React, { useState } from "react"; import PropTypes from "prop-types"; function Foo(props) { const { className, ...rest } = props; return ( I'm fancy component {rest.arg1} but I could become {rest.arg2} eventually... ); } WidgetArrows.propTypes = { arg1: PropTypes.string, arg2: PropTypes.string }; WidgetArrows.defaultProps = { arg1: "foo", arg2: "bar" }; export default WidgetArrows; ``` Which type of commit should this one become? 4) Or even better, what happens when you change the style of that component without modifying the public interface? I'm aware you're suggesting `style` in the specs... but that type won't modify semver. Even though, these sort of changes are relevant to the clients and they need to be aware of new package versions when these sort of "improvements"/"enhacements" of existing features happen. Shouldn't the specs resolve this sort of ambiguity somehow? Is this a feat or a fix? Is it maybe other type that should also modify semver? At the end of the day semver should be driven mostly by public API pinned to customers/clients. But visual modifications, visual enhacements or feature updates will have obviously impact on customers so it should be clear which type to use and how that'd should affect semver. At the end of the day new versions means some existing customers will spend money updating their products against your libraries, so deciding if they want to spend the time on a patch or a minor update definitely it's a big deal. Thanks in advance!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#162