Problem/Motivation
The naming of the current default legacy development branch 8.x-1.x does not follow the standards of semantic versioning which seem to be preferred now, see:
- Drupal Core Change record: Drupal.org release version numbers allow semantic versioning
- Blog post: Drupal module semantic versioning for Drupal core support
Besides, module's new development branch 2.0.x appears to properly apply these standards which seem to work quite well for the creation of tagged stable releases.
Proposed resolution
Move developments from 8.x-1.x to 1.0.x:
- Create the new development release 1.0.x-dev cloned from 8.x-1.x-dev.
- Create the new stable release 1.0.0 marked as supported and recommended.
- Set release 8.x-1.4 as unsupported and not recommended.
- Any other tasks.
Examples of the similar issue for other modules:
- #3212252: Switch to semantic versioning
- #3116560: Switch to Semantic Versioning
- #3193283: Switch to semantic versioning and set core_version_requirement to version 8.8, and 9
- #3123907: Switch to semantic versioning 4.0.x
Important note:
Based on the documentation: Transitioning from 8.x-* to semantic versioning
When your project switches to using semantic versioning, you must increment your major version. For example, if the latest release is
8.x-3.5, your next stable release will be4.0.0
Which means that in our case transitioning from 8.x-1.4 would bring us to 2.0.0, which unfortunately is already taken (by new development branch 2.0.x).
Therefore, we opted to try slightly bending the rule and go for 1.0.x, but if this doesn't work we could take the next available increment 3.0.0.
Feel free to let us know if you have any questions or concerns on any aspects of this ticket or the project in general, we would be glad to help!
Thanks in advance!
Issue fork block_class-3463909
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
dydave commentedQuick follow-up on this issue:
Tried cloning legacy development branch 8.x-1.x to new 1.0.x locally, then pushed:
It seemed to work and the branch was visible in the GitLab repo.
However, when I tried creating a new development release under Add new release with 1.0.x selected, the following error message was displayed:
Therefore, the second option had to be selected, with the next major increment: 3.0.x.
Last build on 3.0.x seemed to still pass 🟢
https://git.drupalcode.org/project/block_class/-/pipelines/249439
Releases on the project page were updated to reflect the fact:
Release 8.x-1.4 was marked Unsupported in favor of Recommended 3.0.0.
At this point, all the work expected in this ticket should have been completed, thus marking it as Fixed for now.
Feel free to let us know if you have any questions or concerns on any of the latest changes, this ticket or the project in general, we would surely be glad to help.
Thanks in advance for your feedback, reviews and comments!
Comment #5
szeidler commentedWhat's the state of 2.0.x and 3.0.x now? Which version is the more modern one, active development is being made on?
Is it possible and recommended to go from 2.0.x to 3.0.x? Because if 3 is the new 8.x-1.x wouldn't it be like going backwards?
Comment #6
dydave commentedThanks Stephan (@szeidler) for your feedback on this.
8.x-1.x ==> 3.0.x, is basically the original version of the module, based on the port from D7, where a single field
CSS classesis added to blocks' configuration form:https://git.drupalcode.org/project/block_class/-/blob/3.0.x/config/schem...
2.0.x is a new version of the module, with quite a lot of new features, such as support for CSS attributes, bulk operations on classes, etc...
https://git.drupalcode.org/project/block_class/-/blob/2.0.x/config/schem...
Note that currently 2.0.x has quite a few issues and is still a work in progress: if you look at the issue queue you should see quite a few issues related with autocompletion and various other PHP related issues.
3.0.x has a much smaller scope of features and has existed for much longer, therefore it is probably much more stable.
We plan on updating both branches documentation and more generally the project page to provide more information on supported branches.
Not sure if I was able to answer your questions, but feel free to let us know if you have more or if you would need more information on any of these branches or the project in general, we would surely be glad to help.
Thanks in advance!