Skip to content

History

Jeff Felchner edited this page Sep 15, 2017 · 7 revisions

2008

Back in 2008, when Ruby was just beginning to become popular, a person by the name of Satoru Takabayashi created ruby-progressbar. Back then, the convention for a lot of library names was to put ruby- in front of whatever the library's name was. Hence ruby-progressbar instead of progressbar.

It was the first and only option for a text progressbar in Ruby.

2009

Around 2009, Jose registered the gem name progressbar and (presumably because ruby-progressbar wasn't being maintained) forked ruby-progressbar to his progressbar repo and started making improvements on it.

Also around this time Natalie Weizenbaum got in touch with Satoru and together they added ruby-progressbar to Github.

2010

Throughout 2010, Jose continued maintaining progressbar and released new versions.

Around this time I was becoming a burgeoning Ruby developer and I was looking for a simple project to maintain to help me learn the ropes and get my name out there. I came across ruby-progressbar because that was what fuubar was using. At the time it was created and maintained by Jeff Kreeftmeijer. I've since take over responsibilities for that as well, but that's another story. 😄

I reached out to both Natalie to see if she was interested in giving up ownership of ruby-progressbar. She said she was and transferred the repo over to me. I also reached out to Jose to see if he was interested in the same deal (even back then I'd wanted to merge them) but he wasn't interested at the time.

2011

I actually sat on ruby-progressbar for about a year before starting the refactoring in earnest. My plan was to completely overhaul how the progressbar behaved and add features that (at the time) no other progressbar library was doing. In addition to this, it was going to be fully tested, be part of an automated build pipeline, was going to follow strict SemVer and I was going to do my very best to make sure that it was never going to require a major version bump (breaking change) as well as to support Ruby 1.8.7 for the foreseeable future.

During this time Jose Peleteiro was making minor changes to progressbar, but for the most part he considered the gem feature complete and wasn't adding new functionality.

2012

My caution over not wanting to do a major version bump, kept me at pre-1.0 versions until July of 2012.

Once the gem hit 1.0, because the changes from 0.9 to 1.0 effectively involved a complete rewrite and a ton of new features, there were quite a few edge cases that needed to be fixed. Thanks to ruby-progressbar's widespread adoption, there were many users to help with the debugging.

2013

progressbar didn't see any updates in 2013 due to Jose feeling that it was basically "done".

ruby-progressbar on the other hand including adding "throttling" so that the bar update can only happen a certain number of times per second, other massive performance improvements, the ability to display an "unknown progress" animation, log output to the screen without disturbing the bar, support for non-TTY output (CIs, files, etc), and allowing the bar to properly display colors. As well as a ton of bug fixes.

2014

2014 brought the "rate" component to allow you to see how quickly the progressbar was processing items (or downloading files). Additionally in 2014 ruby-progressbar underwent a huge internal refactoring. While keeping the tests passing the entire time, just about every file was changed and almost all of the underlying architecture was rewritten. This was all done without breaking backward compatibility.

2015

This year was mainly focused on bugfixes and adding documentation. The expansive wiki was added including animated GIFs to showcase how the progressbar worked.

2016

In 2016 there was a vulnerability that was an issue for gems which had dashes in their names (eg ruby-progressbar). There was nothing I could do personally about that, but seeing as I wanted to ensure I could help out as much as I could, I took it upon myself to begin signing every commit and gem release with a private key which could be verified by my users.

I also reached back out to Jose because he had posted that he was looking for an alternate maintainer for progressbar. Obviously I jumped at the opportunity and put plans together to merge the two gems.

So today we now have two of the most popular progressbar libraries under the same roof and we get all the benefits that brings.