Switch to semantic versioning legacy 8.x-1.x development branch

Created on 26 July 2024, 4 months ago
Updated 26 August 2024, 3 months ago

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:

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:

 
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 be 4.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!

📌 Task
Status

Fixed

Version

1.0

Component

Miscellaneous

Created by

🇫🇷France dydave

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @dydave
  • Pipeline finished with Success
    4 months ago
    Total: 223s
    #234361
    • DYdave committed 79316bf1 on 3.0.x
      Issue #3463909 by DYdave: Dropped support for D8 and minor update of...
  • Status changed to Fixed 3 months ago
  • 🇫🇷France dydave

    Quick follow-up on this issue:

    Tried cloning legacy development branch 8.x-1.x to new 1.0.x locally, then pushed:

    git checkout 8.x-1.x
    git pull
    git checkout -b 1.0.x
    git push origin 1.0.x
    

    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:

    Semantically-versioned releases for this project must start with 2.0.x, or higher, to not conflict with existing 8.x-1.x releases. See documentation on Drupal release versions .

    Therefore, the second option had to be selected, with the next major increment: 3.0.x.

    • Created the new development release 3.0.x-dev from branch 3.0.x.
    • Dropped support for D8.
    • Minor changes to the README.md file.
    • Created the new stable release 3.0.0 .

     
    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:

    Support for 8.x-1.x-dev is now dropped in favor of 3.0.x-dev .

    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!

  • 🇩🇪Germany szeidler Berlin

    What'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?

  • 🇫🇷France dydave

    Thanks @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 classes is 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!

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024