SEP V023: SBOL Visual specification change workflow

[jakebeal]

This SEP codifies expectations about how to propose and implement changes in SBOL Visual.

https://github.com/SynBioDex/SBOL-visual/blob/master/SEPs/SEP_V023.md

At the moment, it lays out the rationale and a sketch of all things that need to be filled in, but is not yet complete.

[jakebeal]

The SEP draft is now complete and ready for discussion.

[chofski]

This all looks good to me and great to see a clearer outline of the process.

[hasanbaig]

Looks good!!

[jamesscottbrown]

Glyph pages

• Before specification release
  • Specification glyph pages: should be automated in the future
    • In the specification/glyphscript subdirectory, add new glyphs to the appropriate .tex list, then run glyph-to-page on all new or changed glyphs.
    • Running all glyphs is not a good idea, because the PDFs all get regenerated with new datestamps, which obscures the actual change in the diff.

This process will become:

• Before specification release
  • Specification glyph pages: should be automated in the future
    • Update scripts/glyph_list.json to add new glyphs, and update the lastEdited value of modified glyphs.
      Then run scripts/rebuild_glyphs.py
    • This will only regenerate PDFs with a modification timestamp that is earlier than that of their source directory

Samplers

Samplers should be automated

If everything works correctly these will be automatically updated, and the website should be able to hotlink to files in https://github.com/SynBioDex/SBOL-visual/blob/master/sampler (these don't exist yet, as the pipeline hasn't run yet)

Glyph collection zips

Glyph collection zips should be automated

If everything works correctly these will be automatically updated, and uploaded as build artefacts. However, I think that they are only available temporarily (and at non-guessable URLs) so someone should copy them across to the SBOL webpage.

Longer tem, they could be automatically uploaded to an S3 bucket or scpd to a server.

[jamesscottbrown]

The list of glyphs in scripts/glyph_list.json is currently manually maintained, but I'm not sure whether it should eventually be be replaced by the ontology (which would need to be automatically updated, and also expanded to record the version of the spec that last changed each glyph), or whether it should be used when generating the ontology.

[jamesscottbrown]

Copying the specification PDF to specification-releases/ should probably be included in either the list of steps to make a release, or in the Derivative Material section.

[jakebeal]

I've updated the SEP slightly based on my experiences applying the release workflow for 2.3, adding some bits I'd forgotten to write in.