As another commenter pointed out, you can recompile the .less files, excluding what you don't need. You can also use the web customizer in our hosted docs at getbootstrap.com.
No, we don't use Jekyll for our blog. It's part of the GitHub.com codebase I believe.
For chat, all standard stuff really :). We use Campfire for group chat (dozens of rooms), Gtalk/AIM/etc for individual chats, and Skype or FaceTime for video chats.
Really? I have had a look at bootswatch.com using IE8 and a lot of the stuff (certainly columns, drop-dows, and navbars) doesn't work at all. I just get javascript errors. I would contend that if you want something that works in IE8 then avoid this like the plague. Unless someone can tell me differently.
Yeah, sorry about those changes in the RCs. Really we used the wrong label and are sorry about that. All in all though, everything with those pre-releases worked out really well. Just a naming thing :).
I appreciate the apology. I updated a site on the assumption that RC1 was a release candidate and not a work in progress. Now I need to update the site again. Ugh.
I generally prefer using Major.minor.1 or Major.minor.2 of a new version (as many more bugs get fixed in those versions, after the stable version is used in production environment) or the last major version with all bug fixes.
That's great, there are a couple of sass ports for 2 and it was time consuming evaluating them so an officially blessed port would be great.
For those of us integrating it with web app where we use semantic class names that we want to map to template styles, it would help if there were sass versions that create no concrete styles, just mixins and placeholder styles, so that we can extend our classes with bootstrap ones without inheriting styles on elements where we don't want the bootstrap style. e.g. I wanted the .nav-tabs style but already had my own .nav styling.
Do you have any plans to make it possible to extend from bootstrap in this way?
Naming changes were for consistency across the framework.
We only use `!important` on utilities where specificity would make them impractical. Quick floats, toggling by viewport size, etc make it necessary unfortunately. When it comes to every other component though, we don't use it at all.
Major version release enable us to break backward compatibility. Other motivations aside, I see no reason to not do it in attempts to do something better.
> Naming changes were for consistency across the framework.
Can you elaborate? Bootstrap framework? so somewhere else you has mood swing and started calling 'xs' and now you want to update the rest of your framework? OR you talking about something else?
> Other motivations aside, I see no reason to not do it in attempts to do something better.
I have been in IT only last 28 years, but until now its been a normal thing that the new version is compatible with old one. Check newest MS Word you can still open Word 97 documents.
What you doing here is you are discouraging those who trusted your framework from spending hours and hours rewriting their codebase to match your newest release. Most will not achieve that, so internet will be infested with outdated bootstrap websites. One could say "nothing wrong with that, noone force you to trust bootstrap", and they will be right.
On that note, anyone can suggest alternative Framework with more mature approach to new release compatibility?
>Check newest MS Word you can still open Word 97 documents.
It's not really a fair comparison at all. One is a stylesheet, the other is a desktop office application.
>but until now its been a normal thing that the new version is compatible with old one
Not true at all, look at Python 2->3, PHP 4->5, jQuery 1.x->2.x. Major releases often break backwards compatibility.
>from spending hours and hours rewriting their codebase to match your newest release
Design is not something you have to rewrite to 'match the newest release', there are no security vulnerabilities in a style sheet. It is fine to stay in Bootstrap 2.
Is there a way to communicate that to users better? I don't think a lot of devs understand that it's easier to build up on a flat button as opposed to trying to overwrite stylesheets on a gradient button. Maybe something in the features for the final release that helps developers understand that it's not flat for flat design, it's flat because it's easier to build on top of.
True, we could be louder about that. I'll get a tweet out about it shortly. To be honest I totally forgot about even mentioning it anywhere but in a few @ replies and issues on GitHub.
Yeah we probably should have called them betas, but I'm fine with using RC—beta sounds way less serious and we want folks to just go to town on this. It's helped a lot.
I agree with the parent. The term "Release Candidate" comes with certain expectations, including but not limited to: feature freeze, API freeze, and few(er) serious bugs. Calling Bootstrap 3 in its current state an RC is misleading to developers and may adversely impact the project's reputation.
With that said, I've been using the 2.x releases on multiple projects over the past year. Thanks for all of your hard work!
The rapid rate of change has definitely made getting Jetstrap to support the latest releases harder, but in general it's been a huge pleasure to use and MUCH easier to extend and customize. Great work! :)
I've been using the WIP for a few months and the changes in RC2 are looking really great. I am curious as to what the ramifications will be on the learning curve of people really making the most of the new grid system and how it can be way more dynamic by calling different columns at different snap points. I didn't really "get it" right away, but after figuring it out I can see how it's a huge step forward.
I've been upgrading one of my apps to RC1 the past 3 days. I think it's great! Lot more easier to get it responsive. I was always having troubles with nested columns on the previous version. Things seem to work a lot more better now! Was about to tackle an issue about getting column structure to remain same on phone devices but looks like RC2 takes care of that with .col-xs !
