Skip to content. | Skip to navigation

Personal tools

Sections
You are here: Home / Versioning: StaVS

Overview of StaVS: a Stabilizing Versioning System

Everything about StaVS, the Stabilizing Versioning System that Evolvix critically depends on. We have been developing it to support the long-term backwards compatibility required by evolutionary systems biology. Here you can find a growing overview, including vision, activities, invited feedback flows, and why you might even want to consider using StaVS outside of Evolvix.

The Stabilizing Versioning System (brief: "StaVS") described here is generally useful and is being designed to support a very wide range of use-cases. This is necessary in order to meet the design requirements for using it in the context of Evolvix. As a result, our system is likely to be useful for independent developer communities as well. Due to the fundamental impact of versioning systems on the software development processes, it is much easier to adopt a system like this one at the beginning of a project to avoid costly code re-organizations. 

 

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.