Draft practices for versioning packages

[jakebeal]

I have distilled some discussions from iGEM on how to version packages given the length time between ordering designs and finding out if they can be produced.

[noahsprent]

Thanks Jake! It's an excellent summary of our discussion, and I think makes sense for our workflow in the distribution for now. I still feel like we're missing a few things for the more general cases, or at least I'm missing understanding a few things . For example, how does one distinguish between software and wetware packages? If one sees that a release is a release candidate, then they can infer from that that the maintainers are currently trying to build the package in wetware. But how is one to know when seeing a non-rc whether this means the package has been physically built or just that the package isn't intended to be built? And what if certain parts in the package have been built but others have not?

[noahsprent]

Again, just throwing out thoughts here, but I'm wondering if maybe representing the physical status of packages needs to be done in a way more akin to testing rather than releasing. In the same way that one can release a version of a software package that is failing tests (although it isn't recommended), one could release a version of an SBOL package where not all of the parts have been synthesised. The repo would have a badge saying "53% synthesised" or something like that. Tracking of whether or not a part had been synthesised or not could be done using the existing SBOL structure of implementations. All the 'test' does is see which parts have implementations. Some packages could then choose to use the 'release-candidate->release' method to ensure that they only ever release with 100% build coverage, but for those packages which don't intend to be built, or ones where they contain parts that shouldn't be built, one can quickly see which parts have been built and which haven't.

[jakebeal]

@noahsprent I think that the tracking and build badges are a great idea, but I think we should go through the exercise a couple of times and experiment with it before we add it to the SEP, since I'm not quite sure what's going to make sense in terms of keeping that information in the package vs. in build artifacts vs. in external databases. I've added a note trying to capture the idea as future work in the discussion section.

I likewise think that we should leave the "software vs. wetware" undefined for the moment, since right now everything we're doing is wetware-focused.

[noahsprent]

@jakebeal Good point! No point trying to optimise everything too early. It would be nice in future workflows to be able to distinguish between sip importing a physical part to represent someone sending you a strain. e.g. iGEM teams from the distribution, vs a design that someone has created e.g. the distro importing designs from other packages to then synthesise. But again, I'm getting overexcited and that's for the future!

[jakebeal]

Merging per discussion with @noahsprent and @vinoo-igem