Version numbers for iGEM distributions

[jakebeal]

We need to decide what type of version numbers should be given to iGEM distributions.

In my view, there is a critical decision fork between year-based releases and semantic versioning.

• Semantic versioning is the standard way software releases are described in terms of "1.0", "2.1.4-prerelease", etc. This indicates when materials are expected to be backward compatible or not.
  • Advantage: this is a near-universal software standard, so software tooling will understand how to interpret and compare versions. If somebody wants "the most chromoproteins after version 2.1" it's easy to know what that means.
  • Disadvantage: relationship between year and release number is broken.
• With a year-based release, we would call the releases "2022", "2023", "2024", etc.
  • Advantage: Intuitive meaning for the release number
  • Disadvantage: If we make corrections to the information about a release or change to more frequent releases, we'll need to reinvent something like semantic versioning
• We could also do a hybrid, which uses the year as the major release number.
  • Advantage: compatible with semantic versioning, but has a year in the number
  • Disadvantage: Fails if we ever want to make a second non-backward-compatible release in a year, or if a year is backward compatible with the year before it.

My recommendation would be to use semantic versioning, and to just include the year in the release name, e.g., this year's initial release would be version 1.0, named "2022 Distribution"

[GC-repeat]

Just to better understand the system, how would you call a second release happening later this year defined as followed :

• Same packages but some sequences modified to fix illegal restriction sites. 2022 distribution v1.0.1 ?
• Addition of packages. 2022 distribution v1.1.0 ?
• Addition of new packages and deletion of packages. 2022 distribution v2.0 ?

[GC-repeat]

Would the year be important to know what was available to the teams for a particular season ? If yes, we may need more info like the month as a 2022_05 (May) release would be available for iGEM2022 but not a 2022_11 release.

[jakebeal]

Just to better understand the system, how would you call a second release happening later this year defined as followed :

• Addition of packages. 2022 distribution v1.1.0 ?

Yes.

• Addition of new packages and deletion of packages. 2022 distribution v2.0 ?

Yes.

• Same packages but some sequences modified to fix illegal restriction sites. 2022 distribution v1.0.1 ?

This one's a little trickier and needs a little thought, because we have to decide if a part can have the same name when its sequence has been changed. If the sequence wasn't the one we meant to make (like the J23106 typo last year), then it would clearly be v1.0.1, analogous to if synthesis had produced an incorrect product.

So in general, if we keep the same name of parts and say "the part never should have been that way", then it would be 1.0.1. If we change the name and say "we're removing the old part from the distribution and you should use the new one we replaced it with", then it would be 2.0.

Would the year be important to know what was available to the teams for a particular season ? If yes, we may need more info like the month as a 2022_05 (May) release would be available for iGEM2022 but not a 2022_11 release.

This is the sort of thing that pushes me towards semantic versioning, because it seems like this is better to get from the release timestamp and/or description, rather than trying to encode it into a version number.

[vinoo-igem]

I think semantic versioning is the way to go.

It does raise a separate question on if "distribution" is the right word for the long term. Both from a workflow perspective as we see things scale up, and from a branding/ordering perspective when we would want to move towards an a la carte system for teams. Prior to this the distribution referred to the set of plates that all teams received.

I think we need to consider the movement of packages within a distribution into a new or separate one and vice versa in the future. I believe semantic versioning should be able to handle this.

Ex.

• A small plant package this year is part of a core distribution, but may evolve into a much larger distribution of its own, with its own timeline, organization, and needs.
• We are also currently importing existing FreeGenes collections into our core distribution. We may at any point want to import more existing FreeGenes collections either as part of a "core" or separate distribution.

[jakebeal]

I like this perspective, @vinoo-igem: I envision a shift over time to "the distribution" being more like a "starter pack" set of core tools. In that view, the distribution would ultimately boil down to just a list of packages (at specific versions) to be included in the standard starter pack to tools.