Separate development builds on the Tool Shed

[Tristan Croll]

As per discussions last week, it would be great to have the ability to upload separate "development" versions that appear distinct from "release" bundles on the Tool Shed. The distinction could be at the top level (i.e. both "ISOLDE" and "ISOLDE-dev" appearing in the list of available bundles), or (I think preferably) within the menu system for the one bundle. Where the existing Download/Install buttons are now, there could be pairs of buttons allowing the user to choose the last stable release or the current dev build (decided based on the version strings). I think this approach would have a few advantages:

• you could save space by not permanently storing the development builds, just the release ones. The sizes of the Clipper and ISOLDE bundles are not trivial, and weekly (or more frequent) builds would quickly add up to some serious storage overhead.

• at present, to create a development bundle that's entirely distinct from the release one, I'd have to give it a distinct name in its metadata (e.g. "ISOLDEdev" vs. "ISOLDE") to stop the Tool Shed server from automatically placing it under ISOLDE. That would create some serious headaches when a release version is installed into ChimeraX and replaced with a development version (or vice versa) - you'd have two different sets of bundle metadata pointing to the same code.

So in summary, what I'd suggest is that the Tool Shed server should provide the ability to serve both release and development versions under the one bundle name, making sure to make the release version's "Install" button most prominent (if, of course, it's compatible with the user's ChimeraX version). When uploading a new bundle, the server should recognise the substring "dev" in the bundle's version string, and replace any existing development version when found.

[Tristan Croll]

Any thoughts on this? I'm scheduled to give a hands-on workshop at Diamond Light Source on the 15th (​https://www.iucr.org/calendar/events/types/workshops/icknield-model-building-workshop). I can get everyone sorted out using local wheel files if I have to, but it would be great if they were able to install the latest dev build direct from the ToolShed.

[Conrad Huang]

I think that's a good idea, but I can't promise to get it done and tested by the 15th. I did just fix the toolshed code to display the latest version by platform, and this change would be in about the same place (as well as the upload name-parsing part). I'll try to get to it later this week or early next week.

[tic20@…]

No worries.
 

[Conrad Huang]

We already "supported" "prereleases" by allowing an alphanumeric string at the end of version numbers. Previously, the toolshed will display only the latest version by platform, whether the version is "release" or "prerelease". Now, it will display the latest releases by platforms, and also prereleases if they are newer than the releases. For example, ISOLDE now has five download links: Linux rel+pre, Mac rel+pre, and Windows pre. Can you please take a look and see if that is acceptable?

[tic20@…]

The problem that arises from combining that with my current naming 
scheme is that the last "release" version is 0.9.24, released more than 
a year ago. Since then it's been 1.0b1 (last May) and 1.0b2 (this Jan). 
I guess the question is, should a beta be considered a "release" for 
these purposes?

On 2019-04-05 19:23, ChimeraX wrote:

[Conrad Huang]

I think there should be a "1.0" release made.  Then none of the b1/b2 
releases will be displayed.  After 1.0b2 looks (to me) like "1.0 beta 2" 
and "1.0" is not officially released yet.

Conrad

On 4/5/2019 12:18 PM, Tristan Croll wrote:

[tic20@…]

Yes, those are “beta” designations. In all honesty, I’m at least another few months away from something I’d be comfortable calling “1.0”. I suppose I could just keep incrementing the beta number, but that would start looking silly pretty quickly.

 
 
Tristan Croll
Research Fellow
Cambridge Institute for Medical Research
University of Cambridge CB2 0XY
 

 

[Tristan Croll]

To more fully outline my concerns:

• Not only is ISOLDE itself not completely ready for a 1.0 designation, I'm not really keen to take that step until ChimeraX itself is at 1.0 status.
• What I want to avoid at all costs is releasing a (meta)stable build of ISOLDE built against a ChimeraX (pre-1.0) daily build. Doing that would mean that after any ChimeraX API change, new ISOLDE users would find it broken upon installation - not a good look. That's why I've been restricting my ISOLDE beta releases to coincide with stable ChimeraX 0.x releases.
• Taking that approach, though, limits me to one release every 3-6 months. That holds back the early-adopters who are willing to accept a few bugs in order to see the latest features, and also people like Tom who want to experiment with building upon it.

The upshot is that I really think there should be a distinction between "beta" (designed to be quite stable, for widespread use and testing) and "dev" (bleeding-edge snapshot, use at your own risk).

[Elaine Meng]

this was "feedback" but I changed it to "accepted" because cannot change owner when in "feedback" and I didn't know who was supposed to provide that feedback anyway -- Elaine