Missing v1.15.6.0 release tarball

[Brainzman]

The latest v1.15.6.0 Github release is missing its release tarball. This is unlike previous releases where a tarball was included as a release asset allowing for easy distribution (e.g. v1.15.5.0). This is problematic for provisioning OSL sources for building, and in our case for upgrading the Blender OSL dependency for the next 5.3 release.

CC @lgritz

[lgritz]

Yeah, last month we tried turning on "immutable releases", which sounded like a good idea, but we did not realize that it would interfere with our automatic release signing process and prevented adding the signed tarballs that you're looking for.

There are unsigned tarballs there, which I believe are identical, but the download name is v1.15.6.0.tar.gz instead of the usual OSL-1.15.6.0.tar.gz.

We turned off immutable releases so this won't happen again until we can figure out for sure how to do it right, but in the mean time, that 1.15.5.0 release had been created as immutable, so we can't just add the files after the fact; we would need to do a new release. It wasn't clear to us if anybody relied on automatic downloads of a fixed naming scheme (which would indicate that we needed to do a new release right away just to fix this), or if we could just wait a couple more weeks and switch to the old method in time for the Sep 1 release of 1.15.7.0, at which point nobody would care about 1.15.6.0.

So you tell me, what's least disruptive for everybody?

1. You have your scripts download v1.15.6.0.tar.gz (botched name) until we switch back with the release of OSL-1.15.7.0.tar.gz in 10 days.
2. You revert to 1.15.5.0 until release of 1.15.7.0 in 10 days -- skipping 1.15.6.0, unless you particularly needed something from this fairly small patch release. (This was a small patch release, and the only item that looks potentially important is Sergey's fix for building against LLVM 22.)
3. I could do a tweak release called 1.15.6.1 that changes nothing but forces a new release process that will do the signed (but not immutable) releases the old way and will have the tarball that follows the old naming convention, and you can use that until 1.15.7.0 is released in 10 days.
4. Is there another choice I haven't thought of?

CC: @jfpanisset for visibility.

[jfpanisset]

For the Conan recipes which are used by the aswf-docker project each version has an explicit download URL:

https://github.com/AcademySoftwareFoundation/aswf-docker/blob/main/packages/conan/recipes/osl/conandata.yml

So in an upcoming version that includes OSL 1.15.6.0, it's not an issue for me to (temporarily) revert to the auto-generated, unsigned tarball link.

Given how much time is spent maintaining CI for OSL and OIIO, as well as the regular release cadence, I think it's a better use of available resources to leave this release as is, and go back to signed releases for the next ones, with or without re-enabling immutable releases (depending on whether the GHA workflow to create signed releases in a repo with immutable releases enabled can be figured out in time).

[lgritz]

I've already disabled immutable releases, so yes, going back to the old way for now.
The only other question is whether to just wait until the end of the month and let 1.15.7.0 fix it all, or should I publish a 1.15.6.1 now just for the sake of having the old link name schema?

[jfpanisset]

From my specific perspective I'm OK with leaving things as is and getting back the signed tarballs link schema for 1.15.7.0. I'm about to release 2026.6 / 2027.1 images which will have OSL 1.15.6.0 in them (well, the ci-usd and ci-vfxall will have OSL builds, and ci-osl images will have the pre-requisites to build OSL, as before).

[Brainzman]

@lgritz Right I see, thanks for the detailed answer. Regarding our specific needs for Blender, we do use a form of templated URL scheme for provisioning library source archives, however this template is easily modifiable and far from being set in stone (see the relevant file/line here).

In our case, for the 5.3 library upgrade, we do need to upgrade specifically to 1.15.6.0 for Sergey's fix, however we're just at the very beginning of our library upgrade integration work (which usually spreads over ~1 month) so the simplest course of action would be to simply wait for 1.15.7.0 and bump the version on our side then, especially as we do not continuously upgrade libraries.