Extensions: Development Track

Feature & Design Feedback
1

This is a technical topic aimed at advanced extension creators. Some extensions may want to provide some of their users a beta track, where daily development can be tested.

I will use BlenderBIM as the example case here:

  • There is a stable release every 2 months.
  • There are developer builds which can happen many times a day.
  • They follow semantic versioning:
    • Stable release = version 0.7.10
    • Next developer build = 0.7.11-alphaYYMMDD

There are two main problems here:

  • The Extensions Platform has no track support (so it is aimed at stable releases only).
  • Blender doesn’t sort the builds using the date, so it may be confused by which build is the last one.

My suggestions:

Workaround for the version clash issue:

  • The server-generate tool may need some tweaking to this special case.
    • Right now it will list each version as a new version, but the sorting of what is the latest version won’t work to tell hashes apart.
    • For now my suggestion would be to make sure the hosted .json only has one entry per major.minor.patch version (aka the latest).
    • Or in other words, just remove all the builds from the folder before adding the new daily ones.

I’m not sure how wide-spread the use of dates on the version is. It is not explicitly mentioned on the semver website, and it doesn’t solve the problem of having multiple versions on the save day. I think it is important to clear this out before proposing a fix on the Blender side.

Alternatively Blender could use the timestamp of the files as tie-breaker to determine the order they show on the Extensions Listing API.

3 Likes
4

At the moment my sense is that we have a lot of follow up todo’s for extensions, users & developers are also getting used to this - so anything that complicates the logic further (such as hosting stable/development tracks within a single JSON) is worth postponing.

Assuming we had time for this though, I’d go with something along the lines of what you’re suggesting - we would be better off using separate repositories for different kinds of packages.

Users who want to beta-test an extension should be able to - without having to tediously download & install from disk for every update. How this would be best handled is an open topic. The extension hosting their own repository is one way.

Re:

Workaround for the version clash issue:

Currently the server-generate command doesn’t allow multiple versions of the same extension (when their blender-version ranges overlap).

I’d like to check on supporting version-control backed extension-repositories so technical users could supply a list of GIT URL’s, any new commits would be available as updates without the developer having to package the extension & upload it each time (I used to use vim-plug which supported this nicely).

This has the advantage that extension developers don’t need to worry about hosting their own repository, the down side is - any issues with the GIT checkout and users will likely have to drop down into the command line to resolve.