2.x release vs 3.x release: Which should I use?

Yikes, this is extremely confusing -- is the 2.x branch going to get deprecated? That's certainly the impression from the project page... is there an upgrade path from 2 to 3? Should anybody upgrade from 2 to 3?

I think the smarts incorporated in 2 are a big improvement over 1 -- if 3 is just about adding Drupal core compatibility I wonder why it didn't stay on the 1.x branch?

Almost seems like there should be two different modules.

I think clarifying this on the project page is pretty important so bumping to major.

I don't understand why you would tag 3.0.0 from the 8.x-1.x branch - but whats done is done - but the impact is crazy, as we are going to keep seeing v3 as a recommend update from composer and the available updates page.

If the 2.x branch will continue to be the path forward, maybe it needs to be deprecated, and open a v4 from the old v2?

Given the differing features from the 1.x to 3.x branch, the 3.0.0 version is effectively a downgrade. We're finding that moving to 3.0.0 can break some sites during updates.

I think we have to remove the recommended version from 3.0 and also, why would a module want to two separate feature-set maintained. Isn't it better for folks in 8.x-1.x to just upgrade to 2.x?

Additionally it is very confusing that the contributed module documentation points to settings not available in latest 3.0 branch. It was only my sharply justified brain ;) and memory from previous setups that made me wonder if I am on the right project installed or if there is some downgrading refactoring going on which is not reflected in the docs. Leading me to search issues and start reading this one and wondering if this branch confusion is related. Switching to the 2.x branch brings back the settings.

Just an example (and one of the main reasons why you should use this project over any other Block attribute alike ones at the moment): https://www.drupal.org/docs/contributed-modules/block-class/attributes →

Updating to the latest branch leads to a loss of configuration in cases when an average user follows Drupal core notification and recommendation to update, since the custom attributes setting is not available no more.

I would even consider this "Critical" but I leave it up to others to decide. Since this is branch and project set up related there is sadly nothing issue contributors can do here without maintainers. Feel free to add me co-maintaining and correcting/update the issue and project page if time is limited.

Comment #4 📌 2.x release vs 3.x release: Which should I use? Active is the missing confirmation I spoke about to consider "Critical" from other users.

There seem to be a general release confusion going on here: https://www.drupal.org/project/block_class/issues/3363340#comment-15799590 🌱 Plan for 2.0.12 Release of Block Class Active

From my experience on projects I maintain or co-maintain, reason for such situation it is often a difference in strategy multiple maintainers have in mind or humble over in a rush. So maybe there is clarification between maintainers required. Also some decisions maybe should be discussed together before moving on.

I just released https://github.com/hanoii/composer-should-not - this is something that I had in mind for quite a bit.

What I think should happen is that the module maintainer should release a 4.x being just 2.x but with a higher version.

maintainer should release a 4.x being just 2.x but with a higher version

I can help on this ☝️

Context:
I'm a maintainer
However a little away from the project in the last months due to busy agenda on my other projects
I wasn't the responsible for creating 3.x from 1.x
But I agree with on this initiative, as mentioned on #4
So if you agree I can go ahead with suggestion #10 and releasing 4.x from 2.x

+1 on this -- please make the 2.x version have a bigger number than the downgraded 3.x version!

+1 on this -- please make the 2.x version have a bigger number than the downgraded 3.x version!
Ok, I'm on it

As agreed, created 4.0.0 based on 2.x

FYI: Added a Matrix of compatibly and a guidance for the upgrade: https://www.drupal.org/project/block_class#matrix →

Any feedbacks on this guideline feel free to let me know

Because there are no significant changes between 8.1.x and 3.0.x and zero changes between 2.0.x and 4.0.x it was not necessary to mark the source branches as "unsupported", leading to unneeded security confusion.

It’s expected. Only 3.0.x and 4.0.x are supported and anyone will commit on 8.x-1.x or 2.0.x anymore

Details

• 3.0.x is based on 8.x-1.x
• 4.0.x is based on 2.0.x
• Only 3.0.x and 4.0.x will receive updates
• Old versions won’t receive new commits anymore
• Honestly I understand your point about the message of “unsupported”
• But I can’t mark as “Supported by Maintainers”
• Because is not true, since anyone will update these branches anymore
• And If mark as “supported” it covers security policy
• So would be necessary overhead duplicating effort applying fixing on these old versions
• I’m sorry about the message of “not supported” but it’s the truth
• If someone needs to remove the message My recommendation is updating as mentioned on Matrix - Upgrade Guidance →

* If you are on 2.0.x: Upgrade to 4.0.x
* If you are on 8.x-1.x: Upgrade to 3.0.x

I agree that 1.x and 2.0 marked as unsupported is the correct and best approach.