Some problems after upgrading to version 4.0

Digressions

I’d like to talk about updating the log first:

The last dozen or so version change on less.js are listed in the CHANGELOG.md file. However, the 4.0 changelog is not written here. It’s easy to give others the illusion that this update is just an adjustment of the version number.

Looked at the Release page, before the 4.0 version, it has not written the update log for a long time. If I hadn’t discovered the problem after upgrading the dependency, I wouldn’t have even thought of coming here.

So can you always list the change log in file CHANGELOG.md?

Problem description

After upgrading to version 4.0, the same style is problematic.

Screenshot

Related Codes

<input type="range" />

input[type='range'] {
  width   : auto;
  display : inline-block;
}

input[type='range'] {
  @size : 14px;

  width: 128px;
  height: @size;
  padding   : 0; // To Fix style on IE

  @desktop : ~'screen and (min-device-width : 1250px)';
  @print : ~'print';

  @media @desktop, @print {
    -webkit-appearance : none;
    border-radius      : 0;
    position           : relative;
    vertical-align     : middle;
    overflow-x         : hidden;
    overflow-y         : visible;
    background         : transparent;
    outline            : none;

    .range-style {
      -webkit-appearance : none;
      height             : 2px;
      background-color   : #c1c1c1;
      border             : 0;
    }

    &::-webkit-slider-runnable-track {
      .range-style();
    }

    &::-webkit-slider-thumb {
      .size(@size, @size);

      -webkit-appearance : none;
      pointer-events     : none;
      position           : relative;
      background         : #1de9b6;
      border-radius      : 50%;
      margin-top         : -@size / 2 + 1;
    }

    .range-thumb {
      .size(@size, @size);

      display       : block;
      border-radius : 50%;
      background    : #1de9b6;
      border        : 0;
    }

    &::-moz-range-track {
      .range-style();
    }

    &::-moz-range-thumb {
      .range-thumb();
    }

    &[readonly],
    &[disabled],
    [disabled] & {
      &::-webkit-slider-thumb {
        background : #c1c1c1;
      }

      &::-moz-range-thumb {
        background : #c1c1c1;
      }
    }

    &::-ms-fill-lower {
      height     : 2px;
      background : #1de96b;
    }

    &::-ms-track {
      height     : 2px;
      background : #c1c1c1;
      color      : transparent;
      border     : 0;
    }

    &::-ms-thumb {
      .range-thumb();

      // Fix style on Edge
      margin : 0;
    }

    &::-ms-tooltip {
      display : none;
    }
  }
}

[liby]

Really these are separate issues, and should be submitted as such. But I’ll address what I can here.

It’s just a digression.

The CHANGELOG.md is written automatically from merged commits. I don’t have a good / easy way to update that manually and capture all PRs. And it lists up through 4.0, so I’m not sure what you mean by the 4.0 changelog is not there.

But you don’t list what changes have been made in version 4.0.

Releases will be the place for documenting breaking changes. Not sure of a better way to surface that.

If you say so, let’s look at the Release page, there is no record of any updated content from version 2.7.3 to version 3.0. Is there no breaking changes between them?

Major version numbers in semver represent breaking changes. So I’m not sure I agree with: “It’s easy to give others the illusion that this update is just an adjustment of the version number.”

So you should always list the updates of the version in the same place. Like you said the Releases page will list the breaking changes, the CHANGELOG.md simply captures the contents of the PRS to update itself. It’s your personal preference and many users don’t know this right? Not to mention that, as mentioned above, the Releases page don’t always record breaking changes

I personally think it is not appropriate to write the update of version 2.0 in the Releases page and the update of version 3.0 in the CHANGELOG.md.

Like Cypress, it always lists the updates of each version on the Releases page. Like React-Bootstrap, it always lists the updates of each version on the CHANGELOG.md. Like core-js, it lists the changes made in each version on Releases page and in CHANGELOG.md simultaneously.

Without seeing what your CSS is compiled as between v3.x and 4.x, I’m not sure what it’s doing differently that would lead to that visual issue. Can you compare the compiled output and open a separate issue specific to the difference?

I will continue to follow up.

[matthew-dean]

Ah, I figured it was something like that. I wonder if some kind of console warning can / should be added to root-level division.