This is a recap of some of the old release notes, from GitHub, since I’ve moved the project over from there. It turns out I wasn’t very good at doing release notes - there’s been no actual process for bumping version numbers, no forward planning. I add to bash-builder and bash-libs as-and-when things come to mind, and bump the number accordingly loosely following semver principles:
- patch version changes indicate a bugfix
- minor version changes introduce new features
- including major features, hence 5.3 introducing a major feature and only getting a minor version bump
- major version changes when fundamentally breaking changes occur - or in the case of 5.0, a rewrite happened!
5.0 and archival of 4.x’s broken repository
I developed Bash Builder in my earlier days of using git, and did not at the time know well how to fix a broken repository. I had been using git submodules, and updating bash-libs quite freely, such that I was having conflicts when trying to reconcile Bash Builder branches in turn.
I decided to start clean again, and thus the 5.0 series was started; there was no use of submodules, and instead I started developing alternate ways of keeping Bash Builder in step with Bash Libs’s progress.
The old repository, with full (broken)
.git/ submodule data, can be downloaded still.
In Bbuild 2 I introduced a tool allowing the developer to bundle individual assets into a tarball file, which would then in turn be executable. I removed it in Bbuild 3 due to the sheer ugliness of its implementation and unmaintainability.
In Bash Builder 5.1 I re-wrote that mechanism in a simpler, cleaner manner, such that bash script developers can “deploy” a script, complete with various assets (images, text files, configs, python scripts, etc) as a single transportable file. It takes care of unpacking itself, and cleaning up after itself too.
This mainly came about with my early assertions that “in bash, any program is your library”. Bash remains a preferable tool for writing some parts of automation, but should be able to defer to other languages when appropriate. Trying to do everything in Bash would be senseless….!
5.3 Syntax Sugars
With 5.3 I introduced the syntax sugars mechanism, and set up for further expansion on enabling completely non-bash syntax in Bash Builder scripts. Whereas previously Bash Builder was mostly a file collater, this version turned it into a much more useful and augmenting tool.
$%function syntax and its dependency
syntax-extensions.sh started here.
I viewed this as a massive improvement, because of the weight introduced by the drive for “correctness” in best-practice. Naming and checking variables, and throwing errors when things aren’t up to snuff, should be expected in all scripts - and so it should be easy.
6.1.1 - Run bash-builder code directly
I highlighted 6.1.1 during releases as it introduced the
bbrun tool with which to run Bash Builder scripts directly, including using the
#%include statements and
$%function function signatures.
Notably, this would also allow using
bbrun directly in a shebang line, allowing direct running of syntax-augmented scripts.
At time of writing, we’re at 6.2.2. For the most part, Bash Builder is now stable. TarSH hasn’t needed to change in a while, Bash Builder has sufficient syntax augmentors for alleviating some of the more onerous parts of clean writing as needed, and most tools stand alone fine.
Most of the changes happen in Bash Libs, which tend to change much more frequently as time goes on and more wrappers evidence their need.
On the roadmap is to spin out
bbrun into its own mini-project, so that it comes bundled with its own
bbuild and library set, through the magic of TarSH bundling - it would mean that only
bbrun itself would need to be present on a system wanting to benefit from it, rather than the bbrun script relying on the presence of goodness-knows-what-version release of bash-libs.
I was at one point considering syntax augmentations including a form of dot-notation “object” syntax to implement multi-dimensional arrays of sorts, but I’ve shelved that for the time being owing to its complexity and the overhead that my current design would introduce. That said, multi-dimensional arrays would be ever so practical, so this is certainly not the last we’ll hear of it!
At work, for the benefit of my peers, I am starting to consider moving away from Bash towards Python - the latter is much better known, and is easier to write cleanly for already ; telling people to use a tool that I put together in my spare time, it turns out, is not easy. It’s also awfully slow on Windows, where some of our work is done, further cementing our company’s preference in the arena. I expect therefore that development will be mostly limited to what I occasionally need at work, and mainly my needs for maintaining Git Shortcuts and Alpacka