Skip to content. | Skip to navigation

Personal tools

You are here: Home / Versioning: StaVS

StabVS: the Stabilizing Versioning System landing page

Concept landing page for StabVS, the Stabilizing Versioning System, designed for facilitating long-term backwards compatibility in many contexts. On this page we collect useful info on StabVS. Feedback welcome.

The Stabilizing Versioning System (official Brief Name "StabVS") is being designed to support a very wide range of frequent and rare use cases in order to accomplish its long-term mission for Evolvix.

Thus, even if you do not care about Evolvix, StabVS might be useful for you if you need to pick a high-quality versioning system for a new software project.

Due to the fundamental impact of a versioning system on  software development, it is of course much easier to adopt a versioning system from the very beginning of a project.

For this very reason, properly defining StabVS has been a high priority in Evolvix development is in the process of transitioning from the code base of the currently downloadable prototype to a more sustainable long-term open source code organization. Evolvix requires long-term backwards compatibility (LTBC) for eventually achieving its strategic goals in evolutionary systems biology. StabVS has been developed for implementing some key features that are necessary for LTBC in this context. Below you can find a growing overview of all sorts of info about StabVS, its vision, current and planned activities, invites to contribute to StabVS feedback flows, and the myriad of potential use cases of StabVS outside of Evolvix.

StabVS has been designed to support a very wide range of use-cases as needed for using it in the context of Evolvix and its long-term stability goals required for enabling evolutionary systems biology as defined here (LINK). The resulting long-term design requirements are so general that StabVS will likely also be attractive for numerous independent developer communities who need to pick a new versioning system for any reason and have no interest in Evolvix whatsoever. In fact, StabVS can be easily used without the need for any implementation, just by manually following a small set of naming rules whenever files are copied or changed. We have been doing this internally for preparing files for several publication projects.


2017 January: Introduction to the POSTsystem published by Annals N.Y.Acad.Sci.

The Stabilizing Versioning System critically depends on the StabilizingZone that is at the core of the POSTsystem and aims to contribute to the stabilization of project organization, in addition to helping with the production of the final deliverables of a project. The definition of the POSTsystem was the first full and major test-case for the development of the Evolvix BESTnames system and was consequently published together with the BESTnames paper (see Evolvix page for all about BESTnames).


For a description of the StabilizingZone in the POSTsystem and initial aspects of StaVS development, please see the Evolvix POSTsystem Concept page:


Introduction to the POST System and to Stabilizing Versioning (Stability: RRv1_2016m09d12)


The Stabilizing Versioning System continues to be under review currently. If you would like to contribute to this review process, or have any comments or requirements, criticisms or improvement you would like us to know about, please do let us know. This is long-term effort, so it's worth to take the time to improve the solutions Evolvix development will at some point have to commit to irreversibly.



2017 November: Update on defining PublicVariants (PV) and EncloseVariants (EV)

We recently made major progress by defining the MM...TT versioned variants as PublicVariants (PV), which stand in contrast with our latest addition, the EnclosedVariants (EV). Briefly:

  • PVs are designed for most users and are counting versions upwards (from released code taken as a defined starting point, steadily increasing numbers towards an open-ended future of undetermined variants with no major events scheduled other than continued development).
  • EVs are designed for developers working towards a well defined goal (starting from a defined PV in the past that serves as a suitable base, and aiming to implement a desirable feature-set to be delivered at a defined future PV release that will mark the next release number increase). We we have identified the following EnclosedVariant types that at the core of the developer workflow we have been designing, both for developing Evolvix, as well as eventually for making it available from inside of Evolvix. The EnclosedVariant basic types are:
    • InternalVariant (IV). All new branches that start from a PublicVariant first become an IV. Who knows, maybe that initial idea does not pan out, to it might be better to develop it internally before sharing. Also, ANY other (public or internally shared) branch type can always be turned into an IV to quickly try out things. Such branching is allowed from other IVs of the same owner, however, they are not allowed from other owners (to avoid the git problem of being no longer able to delete some old crappy temporary IV, just because someone accidentally build something useful on it). Thus, your IVs are your's and your's alone! The same is true for the IVs of your friends (who also have to share their code as non-IV, before you are allowed to build on it).
    • FeedbackVariant (FV). To progress towards publication as a PV, an IV next needs to become part of some FeedbackFlow that will be reviewed. Hence, once you decide to share or publish your IV, you will need to transition it to become a FV by declaring it to be one in a corresponding commit (details to be defined). Each FV is meant to be reviewed critically. The effort required for such review will vary substantially from seconds for trivialities to many months in complex cases.
    • OperatingVariant (OV). After implementation and sufficient testing or review, a FV can be declared "operational" by the reviewer/developer working on it. Thus, it becomes an OV, which is a candidate for inclusion into the MainVariant. It might also be called 'MergeVariant', since this is where most code is merged, possibly with disastrous consequences if the testing of previous OVs was not thorough enough or conflicting code from the MainVariant has not yet been considered by an OV.
    • MainVariant (MV). This basic branch type is the equivalent of what might be called 'trunc' or 'dev-branch' in other version control systems. Here it is simply MV, the MainVariant. For lively projects, it keeps getting updates from OVs all the time. Each OV needs to be briefly reviewed by a project maintainter, before merging into the latest MV. MV branches are typically subject to an automatic test suite that tests if the latest additions resulted in the re-appearance of known problems that need to be fixed ASAP. If not, and sufficient functionality has accumulated, then extended user testing might start. Briefly, this follows the typical known scheme of Alpha, Beta, and Candidate from which the best is chosen for defining only exactly one Deliverable that in turn defines each PublicVariant.
    • AlphaVariant (AV). Alpha-testing of new features; these variants are not yet feature complete. Once they are declared to be feature-complete by Alpha reviewers, they must be Beta reviewed.
    • BetaVariant (BV). Beta-testing only starts after features have been declared complete. Beta tests are about stability, tying up loose ends, before becoming a CandidateVariant.
    • CandidateVariant (CV). If all went well, there will only be one CV that will go on to become a DV. However, life is what happens, when we make other plans, so count on last-minute discoveries that will make you go say "Final 2" after you said "Final", and then "Final 3" after that, before "Real Final", "Ultimate Final End", and so on. To avoid these common terminal naming diseases, simply keep counting CVs. If you do, you will be a release manager for your project and should possess the self-discipline to slow down and think before you send an an immature CV to go down the path of becoming a publicly shared DeliverableVariant that in turn defines an equivalent PublicVariant that shall not be removed from public repositories (and in many cases this is essentially impossible; hence think first!).
    • DeliverableVariant (DV). See the warnings about premature deliveries in the previous point under CV. It is impossible to return from here, as declaring a variant to be a DV means that the PV versioned variant counters will have been increase and these are defined to never go back ever. If a DV was indeed screwed up in ways that are impossible to tolerate for public distribution (the night-mare case), then a substitute CV that is free from such problems will need to be prepared ASAP, and be published as the next available Patch. This is done without replacing the problematic patch versioning number, which is then instead labeled to be a KnownKiller (KK), and as a consequence is removed from download pages. Info about the KK status of a PV is metadata that is defined by the POSTsystem (see intro paper above). This meta-data is freely distributed throughout the whole StaVS delivery network in order to make it as easy as possible for as many installations as possible to avoid using any KK variants.  


More details about StaVS are about to follow.