Improve release cycles and version numbers

[ream88]

Some people have discovered that I'm currently struggling to stay updated with the evolving dependencies of this package. Moreover, I'm often uncertain about how to appropriately adjust the version number, as it relies on both stylelint-order and stylelint. Can anyone offer suggestions on how to adhere to semantic versioning effectively?

[nikolaik]

I believe since this repo depends on stylelint-order it should mirror their peerDependencies. When they drop supporting a major stylelint version, you should update with the same. If you drop support for a major version of stylelint (by updating peerDependencies this package should also bump its major version.

[mutoe]

Usually, if your code doesn't have any changes, but only the version that the parent depends on, you only need to update the patch version. Users don't care that a dependency of your project is broken.

Once your project has a break change or feature add, you can make a major or minor update to notify the user that your project has been modified and requires the user to make appropriate adjustments to the configuration.

For the current project, I recommend updating the patch version and declaring peer dependencies as stylelint: ^14 || ^15 etc.

[mutoe]

https://stylelint.io/migration-guide/to-15/#breaking-changes

This is the break changes for stylus 14->15, I don't think these modifications have any impact on users using your project, so there's no reason to upgrade major version.

[julienw]

Yeah, I believe that as long as the plugin works with older stylelint-order versions, you can keep them in peerDependencies and just add the new ones, releasing a new patch version.
If this starts to be painful (for example stylelint-order or stylelint requires you to change the code), then you can remove some older versions and bump the major version.

[stevensacks]

There are a few ways to write it. The easiest way is to add the new version after an || (assuming your library works with both versions).

"peerDependencies": {
    "stylelint": "^14 || ^15"
  },

Whatever solution you choose, the only thing that matters is to take a couple minutes and update the peerDependencies to support a new major version so people can continue using it.

Oftentimes, you'll find people will create PRs on your behalf so all you have to do is merge them in.

[tay1orjones]

@ream88 Personally I'd favor more frequent major/breaking releases than avoiding releases altogether trying to figure out if the dependencies changing warrants a major or minor version bump. There's no downside to having new majors of this package with small deltas.

So i'd say to keep it simple - if either stylelint-order or stylelint are updated to a new major, cut a new major here.