Getting to Bootstrap v4
github.com
github.com
The response to this highlights something I've noticed watching Open Source stuff for a while: this attitude that a piece of software can never simply be finished, but that it must constantly be changing to be alive.
This is a good example of that. Bootstrap 3 has been out for a while and it mostly works for the things it was designed to work for. If you look hard enough, you can find bugs and situations where it's not suitable to use. But that's fine. It's a super valuable thing that we all get for free. The new site I'm building on it looks way prettier than it ever would if I was designing it myself, and will remain so indefinitely, even if these guys never commit anything else to the project.
I don't see anything wrong with the guys who built it stamping it "done" and moving on to the next thing.
It's a pile of CSS and a few scripts to show and hide things. And it has had three years of effort put in to make sure everything works mostly as it should. That's not going to change.
We're just not going to get anything new. It was fine for production use yesterday. What has changed that makes it less fine today?
"you can easily fix most Bootstrap bugs by overriding it with some custom CSS" vs. "you can easily fix most [imperative/OO/functional programming language's library] bugs by overriding it with some custom [code]"
and
"just not use that CSS class" vs. "just not use that [method/function/class]"
An contrived example: let's say an unfixed Bootstrap 3 bug is that there is a formatting error when rendering "div.jumbotron > h1 > span.label > small". You could replace the last small with you own css class and be done.
Contrast that to a bug in Angular, for example, that enabled a XSS bug. You'd want to upgrade Angular, instead of manually patching or adding a workaround to all your forms.
That's what I was thinking, at least.
Then why say that you're ending the support for Bootstrap 3? Clearly something IS not going to be done from this point onward, and it's that thing which is worrying people.
What they are not "ending" at all is "We still recommend v3 for production and believe it to be stable".
The complication here is the two meanings of "support" of "recommendation to use for your production efforts" versus "we are actively helping a tiny fraction of users with long-tail bug reports".
Bootstrap 3 is probably more stable than the CSS most people typically write in all probability. I don't see the problem here, and this typical knee jerk reaction to carefully made open source decisions really sucks & does a disservice.
IMO, the "not your vendor" line is perfectly reasonable when we are talking about code that was just made available by posting it in a GitHub repo or a blog. Once the members of a project actively promote their product to other people, and happily witness very large numbers of people take the advice and use the product for years in their own projects, I think that it's rather a breach of trust to suddenly change their minds.
The minimum that could have done is given notice that they were struggling for resources and given people in the community an opportunity to help, and perhaps even request that someone from the community step up and become Bootstrap 3 maintainer to handle any necessary bugfixes until users could transition to Bootstrap 4.
The only unprofessional thing is the entitlement to someone else's time.
I wish there was an easy way to crowdfund maintained releases. I've been burned by 3 frameworks moving on with no backwards-compatibility; that was worth money to myself & my business to keep them maintained.
Unfortunately, not enough to hire someone full-time or coordinate it (the original developers in all cases had no interest).
Does this exist?
Sometimes, there is a time to call a three-year-old project stable and move on.
I finally moved a new project to v4 alpha for some newer features because I'm tired of waiting. It's not ready for production yet so I'm happy to see this renewed focus for the main devs on v4.
Yet, I understand people having concerns with them dropping support for v3 not having the v4 in a production-ready stage.
But like you said, developers might as well get their hands on the alpha to and see by themselves if the use they make of the library suits their needs and works fairly well. For most people, even an alpha version will probably work fine.
The problem often is the delta between perfect, and done. It's hard, as a creator, to realize when something is great in other people's eyes. The creator looks at their work and cringes. Everyone else looks at it and claps. It's that delta that creates the drive for perpetual development.
Given that, knee-jerk reactions to the mass closing of issues surely won't come as a surprise, but it also should make for some interesting debate. Is that the best way to stamp v3 "done"?
Development is probably stopping on v3, sure, but that doesn't mean it will completely be unsupported and ignored. Let's say there is some major bug in v3 that comes out soon, you better believe it will be addressed. Otto just wants to push faster on v4 by dropping all existing split dev work.
On the other hand, slapping "Don't care" label on all the issues of the current stable version seems... bit excessive.
All in all, makes me happy I only use bootstrap for the CSS, and not the JS-based interactions.
This news, not even 24 hours later, confirms others' and my fears [5], that v4's arrival will mean the cessation of releases -- including bugfix and maintenance releases -- on the v3 line, effectively making it abandoned.
[1] https://news.ycombinator.com/item?id=12432136 [2] https://news.ycombinator.com/item?id=12432546 [3] https://news.ycombinator.com/item?id=12433663 [4] https://news.ycombinator.com/item?id=12432666 [5] https://news.ycombinator.com/item?id=12432915
Every user is free to make changes themselves but upstreaming them to the 'official' repo won't work, because the devs have decided they've moved on. Everyone is free to maintain a publicly-accessible fork, but without community coordination, the forks will diverge, unless widespread community consensus is reached about which one is the preferred survivor repo. Essentially, to solve the problem, merely dumping code isn't sufficient; you must also build a community.
Hence when a project's leadership decides they will no longer release/maintain/fix/accept-pull-requests-for a particular version, all of us lose the single most logical place where collaboration about that particular version happens. This is what I lament, not that woe-be-unto-me, I-have-to-fix-it-myself.
Not sure if I mean that sarcastically or not.
Maybe a fund-raise to have someone work on it full time, the way like what vue.js does?
Thanks.