Plan for Bootstrap 4

I have already told you why this issue/topic is postponed, several times, and will get to it when it's time to do so.

Please stop.

Please stop.

@markcarver Frankly, I cannot fully understand this attitude. Could you please give us, BS theme fans, a glimpse on why you wouldn't like to accept @dillix's help?

My personal considerations:
1) BS 4 is now in Beta and the authors mentioned that they are not going to break compatibility.

Long story short, shipping a beta means we’re done breaking all your stuff until our next major version (v5). We’re not perfect, but we’ll be doing our best to keep all the classes, features, and docs URLs as they appear now in this release. We can always add more things, but we cannot take away.
https://blog.getbootstrap.com/2017/08/10/bootstrap-4-beta/

2) As I understand, @dillix has been using BS 4 for a while and his business somehow depends on it. Thus, he forked the project and started porting it. In other words, he is not pretending to compete with your theme. Instead, he would like to join forces and he informed you about his positive intentions many times.

3) In this thread https://www.drupal.org/node/2554199 you first said that you're busy to port. Then you were waiting for a beta release. Now you are waiting for RC. What are your real intentions on not allowing @dillix to help with the port? You don't trust him? You could potentially coordinate the porting process, split it to tasks and review each and every PR to be sure that everything is ported properly. You could at least allow the discussion going.

Frankly, I cannot fully understand this attitude.

For some reason, you both are interpreting the "Postponed" status as "Closed (won't fix)". That is not true.

It is merely postponed (e.g. its status will change back to "Active" once an RC has been made), thus that is why I closed this issue as a duplicate of that one.

I have said and will say again, that this issue/topic just a matter of timing.

BS 4 is now in Beta and the authors mentioned that they are not going to break compatibility.

That's what they say, but not always the case. I have had experience with chasing alphas and betas before, it really is not fun nor an efficient use of anyone's time. Especially when you're the one responsible for a project that affects thousands of sites. That is my responsibility as a maintainer to take that fact into account when making these kinds of decisions.

As I understand, @dillix has been using BS 4 for a while and his business somehow depends on it.

The reality is that no one is preventing him (personally, on his sites) from making the decision to chase unstable software. That is certainly his prerogative.

When it comes to this project... I am the maintainer, not you or him. This means that all the patches have to be reviewed and tested through me.

Inherently, this creates a bottleneck and forces more of my attention. Attention that I have been focusing elsewhere in preparation for this new version (e.g. abstracting the "non-bootstrap" specific stuff into a separate project and solving versioned templates/preprocessing so we can have both BS3 and BS4 support at the same time).

You don't trust him?

This is not a matter of "trust". It is simply a matter of waiting for things to solidify more on the framework's end.

It's also the matter of maintainership... this is my decision, not yours or his. I have already told you this decision, multiple times, and have explained this decision, multiple times.

Just because you don't agree with this decision doesn't mean you can continue to harass this issue queue.

It will not change my mind and, in fact, just continue to hurt your case.

@markcarver Thank you for taking the time to respond.

That's what they say, but not always the case. I have had experience with chasing alphas and betas before, it really is not fun nor an efficient use of anyone's time.

Good point. As a maintainer myself, I agree with you.

Especially when you're the one responsible for a project that affects thousands of sites. That is my responsibility as a maintainer to take that fact into account when making these kinds of decisions.

There are two groups of users, such as early adopters and enterprise users. Early adopters often find their new passion and can change their preferences one day completely. The enterprise users bet on stability and consequently don't upgrade software often. I personally think that the enterprise users are the most loyal ones and the software should first of all follow their needs. Thus, a maintainer has all rights to wait for a stable version of a dependency before including it in their project.

We can just hope that Bootstrap team will release RC soon enough.

@markcarver why not just start a new development version - 4.x-dev branch?

@markcarver why not just start a new development version - 4.x-dev branch?

The 8.x-4.x branch is currently there, only, to facilitate categorizing BS4 issues (d.o requires a branch to exist to utilize the "version" field in an issue's metadata). There is currently no code in it.

because I expect breaking changes in the theme, such as: removed panels, wells, glyphicons font as well as changed build process (LESS->SCSS).

These are changes in the framework, not this base theme.

Two separate entities.

There will be major underlying API changes in this base theme as well, however, if only due to the significant refactoring that I have been currently working on in a separate project to abstract the non-bootstrap specific code (i.e. plugins).

Before porting the theme, I'd like to receive a @markcarver's approval of the idea, so that my port can potentially become a foundation for the 4.x-dev version on D.org and my effort won't be wasted.

No, I do not approve and your efforts will be wasted (for this project anyway).

The current codebase will not be used as the basis for the BS4 code to come. There needs to be significant work to be done [beforehand] to support both BS3 and BS4 code at the same time (not everyone will want/need to migrate to BS4).

Furthermore, the fact that d.o contrib projects lack semver prevents what major version changes go into a branch/release. In the past, we have kept version parity with the framework for simplicity. However, this is becoming increasingly difficult due to the need to support both BS3 and BS4 at the same time.

The goal I have been working on is to abstract the code enough so that either BS3 or BS4 can be used within the same codebase/branch. What that entails though, is to create/abstract enough code so that these versions can be toggled for all aspects of the theme system (templates, various hooks/plugins, theme registry, element info, etc.). Couple this with the fact that the theme system really didn't get the proper architecture overhaul that was truly needed... it has been and is going to continue to be a lot of work.

I am focused on the longevity and sustainability of the project as a whole, for years to come.

You are focused on just a very small and single aspect of this issue/topic: porting [a non-stable, early release of] BS4.

You just want the latest and shiny new toy.

I require stability, reliability, and compatibility.

As someone who has been spearheading this project for the past 5 years and has already gone through the previous major BS version change (BS2 -> BS3), I know what this process actually entails and how much time, energy and effort it will take to get there.

My goal is to make this easier, not harder, for everyone involved.

But this requires patience and understanding from enthusiastic developers such as yourself, qualities that seem to be lacking currently.

Please stop reopening this issue.