History
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.
Around 2009, Jose Peleteiro 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.
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 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.
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 was architected (the behavior would be similar, but the architecture would be much more modular)
- add features that (at the time) no other progressbar library was doing
- be fully tested
- be part of an automated build pipeline
- follow strict SemVer
- do my very best to make sure that it was never going to require a major version bump (breaking change)
- 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.
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.
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 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.
This year was mainly focused on bugfixes and adding documentation. The expansive wiki was added including animated GIFs to showcase how the progressbar worked.
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.
Added the %u format flag which shows ?? if the total is unknown.
There was a major overhaul of how the output stream was handled. I added the ability to have modular output classes for varying situation. Primarily this consisted of a "TTY" and "non-TTY" version, but I also added a "null output" which displays nothing, and also allowed users to pass in their own custom output objects so that they could (for example) output to a different location like a log file.
Additionally, I added a hash output to display the full running information about the bar which could be consumed by a script to change behavior based on that information.
Lastly, thanks to a user contribution, we added an Enumerator refinement which allows users to create a progress bar and automatically increment it as the enumerator loops over its items.
Not a lot happened in 2018. Primarily I just added the %W format flag to represent the complete bar with an integrated percentage.
Again, a pretty slow year and only did general maintenance, test fixes, and CI updates.
The big update in 2020 was converting CI over to Github actions which ended up being much more stable and easy to work with than Travis or CircleCI.
Another addition was adding the RUBY_PROGRESS_BAR_FORMAT environment variable which allows users to set the format even if they don't have access to the underlying code. In this way if you wanted to, for example, change how the Rubocop progress bar looked, you could set the environment variable before running Rubocop and it would behave as you expect.
A slow year and no user requests or updates.
I missed my end of year maintenance and so all of it got pushed into the first part of 2023.
Huge changes for ruby-progressbar this year. For starters, the refinement was completely refactored so that (hopefully) it does the exact same behavior but is drastically simpler. On top of that we now allow access to the bar as the block is executing so that if, for example, one wanted to log to the screen in the middle of the block, they can now do that. This was done with backwards compatibilty in mind.
But the biggest change in 2023 was converting the smoothing calculator into a larger concept called a "Projector". Projectors are used to estimate the amount of time each future item will take to complete in the bar. After this change we now have the ability to change the strategy used for the bar to make that estimate. This was also done in a backwards compatible way.
