Labeling version variants is typically deemed trivial busy work by computational biologists, computer scientists, and programmers. Surely, the real action happens elsewhere—or does it? While versioning alone does not make computers useful, versioning problems in today’s complex interdependent software packaging jungle can easily knock out otherwise powerful functionality. Similar problems can plague computational biology, where biosystems curation improves datasets over time, but dependent results become meaningless without respective versioning details.
Versioned Biological Information Repositories can enable accurate citations that link precise causal data to a given conclusion. A good versioning system helps avoid unnecessary complications from miscommunicated versioning information. Such efforts are essential for achieving long-term stability of complicated networks of code and data repositories that are independently maintained. Stability despite independent maintenance is essential for progress in grand research challenges that require worldwide communities of researchers to collaborate, such as when implementing the complex fitness causality networks that underpin the fitness landscapes studied in evolutionary systems biology . In the resulting networks of VBIRs, data errors in one VBIR can ripple through many others. If corrections at the source are not passed along with equal efficiency or are bundled with code breaking feature upgrades, most time in research will eventually be spent correcting errors.
Come discover StabVS, a versioning system designed to simplify the communication of versioning info. StabVS combines the stability codes we developed for the Project Organization Stabilizing Toolkit (POST) system with the well-known version-release-patch (vrp) counting system, in order to give each stability code its own vrp counter for communicating patches and releases of new features that remain backward compatible as well as versions breaking backward compatibility (similar to semantic versioning but not identical). The long-term stability of the published API is indicated by the respective stability code and either assessed by authors and maintainers for lower stabilities or by more complex mechanisms that require multiple rounds of rigorous review from numerous angles for more stable codes.
The stability codes of StabVS are defined by these brief, explicit names:
Thus, for example, the second official and backward-compatible release of a package would be called RRv1r2, and code from the first internal hacking experiment based on this release would be RRv1r2_MMv0r0p1 and so on. This system has been substantially refined to meet numerous versioning use cases without breaking, including those of interest for developers, such as alpha, beta, and similar internal releases. To keep StabVS complexity as low as possible it can drop clutter, albeit in well-defined ways so machines can regenerate everything as needed.
StabVS is general and arguably on its way to becoming the most advanced versioning system. It’s creators aim to use StabVS for their own work in conjunction with Jupyter. Others will also likely benefit from improved versioning, whether JupyterLab users, Jupyter core package developers, or kernel protocol designers. While StabVS has reached an advanced design stage (beyond RRv1), not every aspect is fixed in stone yet. Join in to provide feedback on important use cases and potential ways to seamlessly and usefully integrate StabVS and Jupyter.
©2018, O'Reilly Media, Inc. • (800) 889-8969 or (707) 827-7019 • Monday-Friday 7:30am-5pm PT • All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. • firstname.lastname@example.org