Develop protocol for releasing standard bundles onto toolshed

[Scooter Morris]

Moving parts of core out to bundles is a separate task

[Tom Ferrin]

Dedicate a developer's meeting to deciding.

[Eric Pettersen]

Milestone renamed

[Conrad Huang]

Decide which bundles are part of download.
Create mechanism for putting "standard" bundles on toolshed.

[Tom Ferrin]

All bundles should be on the toolshed, but we need a simple procedure for doing this.

[Conrad Huang]

There is now a make sync target in src/bundles/* that will send the already built wheel file to a plato repository. RBVI developers can then go to ​https://cxtoolshed.rbvi.ucsf.edu/apps/devel/release to manually release new bundles or versions. (Developers must be logged in and flagged as "staff member" to use the web interface.) Wheels older than 7 days will be removed automatically. To release an old version, one must build it, send it to the repo via "make sync", and then release within a week.

If a bundle has a file RELNOTES.html at the top level (in the same directory as bundle_info.xml), the file will be copied into the .dist-info directory of the wheel. When released via the web interface, the release notes will be automatically imported into the version history.

Still need a method for releasing all bundles from a release (as opposed to daily) build.

[Conrad Huang]

The consensus is that we will *not* automatically put standard bundles that are included in installers on the toolshed. Instead, only bundles that change versions between installer releases will be manually added to the toolshed by the developers (adding icons, snapshots, descriptions, etc. on first upload). Non-standard releases will also be added manually, as a number of bundles in the repository are outdated, experimental or for testing only and *should not* be on the toolshed, e.g., bogus.