Semantic Versioning issues due to this project being a fork from kenwheeler/slick

[gravelpot]

First of all, thank you for this awesome package. We have started using accessible-slick in our university's custom Drupal distribution as part of a pre-rolled carousel feature, and it feels really great to be able to say that we are using a package designed for accessibility as part of that feature.

We are running into a challenge with the versioning policy for this package and its history as a fork of kenwheeler/slick.

Because our project is PHP-based, we are pulling accessible-slick into our project using https://asset-packagist.org/, which allows PHP projects to pull in NPM dependencies using Composer.

Since this git repo is a fork of kenwheeler/slick, it retains the entire Git tag history of that repo. The most recent tag/release of that project was tagged as v1.8.1 (interesting to note that the "v" was only introduced into the tag naming convention as of that last release -- the prior tag was 1.8.0 without the v).

It appears that when you started creating releases of this repo, you started over with v1.0.0, and the most recent release is tagged as v1.0.1. This is problematic for a couple of reasons:

1. It's confusing for humans who are looking at the version numbers in anything other than a date-specific sort order to determine which is the most recent actual release.
2. A system such as Composer which relies on Semantic versioning interprets the most current release of this repo as being v1.8.1 because 1.8.1 is greater than 1.0.1. If you look at the package's page on Asset Packagist, you can see that the "actual" releases of accessible-slick are listed all the way at the bottom, and the older tags which were inherited from kenwheeler/slick are at the top, because the versions are being sorted in Semver order. As an example, when I create a new Composer project and define asset-packagist as a repository, using the package requirement require npm-asset/accessible360--accessible-slick (which should get the most recent stable version) will pull in version 1.8.1 (see example output below)
3. The version numbers you are assigning in new releases are already colliding with tags from the original repo, with the exception of the "v" that you've added to the tags created in this repo. The "v" prefix, while commonly used, is not valid Semver, and depending on the system that is being used to retrieve the package, that "v" may or may not effectively differentiate the versions from each other as unique.

Since it looks like you intend to move forward with ongoing development and releases, I wonder if you would consider the following suggestions (together, or separately):

1. Tag the next release of this project as 2.0.0 to indicate a new "major release" (using the Semver definition) and to clearly differentiate it from the historical releases of kenwheeler/slick.
2. Drop the "v" prefix in future tags, to be more consistent with Semver for more universal interoperability with systems other than npm.

(I don't know much about npm, but if the v prefix is getting added by npm version, it looks like there is a way to force npm to not use it: https://stackoverflow.com/questions/37788907/have-npm-version-not-prepend-v-to-the-git-tag)

Thanks for considering this suggestion!

Example output from Composer

➜  composer require npm-asset/accessible360--accessible-slick
Using version ^1.8 for npm-asset/accessible360--accessible-slick
./composer.json has been updated
Running composer update npm-asset/accessible360--accessible-slick
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking npm-asset/accessible360--accessible-slick (v1.8.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Downloading npm-asset/accessible360--accessible-slick (v1.8.1)
  - Installing npm-asset/accessible360--accessible-slick (v1.8.1): Extracting archive
Generating autoload files

[gravelpot]

Bump. @pratikbassi Can you weigh in on whether you would be willing to consider this suggestion?

[gravelpot]

Hi @pratikbassi, I'm checking in again to see if you would be willing to consider this suggestion. Please let me know if there's any additional information I could provide to help you evaluate what we're proposing:

1. Tag the next release of this project as 2.0.0 to indicate a new "major release" (using the Semver definition) and to clearly differentiate it from the historical releases of kenwheeler/slick.
2. Drop the "v" prefix in future tags, to be more consistent with Semver for more universal interoperability with systems other than npm.

[recrit]

bumping this issue since it is a major blocker in order to maintain a project. To use the accessible slick, I had to specify an exact version in my composer.json which is bad practice.
"npm-asset/accessible360--accessible-slick": "v1.0.1"

[gravelpot]

Hi @pratikbassi, checking back again to see if you can consider this suggestion, especially now that @recrit has agreed that it is an issue. Appreciate your time in maintaining this project!

[t4k]

Adding support to this suggestion. I am also a Drupal user looking to use this project with Composer.