Think it's better if get_blender_version accepted an optional argument for the header path so that the caller is responsible for setting the same relative to itself, instead of the function guessing who's calling it and from where.

For the records, we used this to generate the blender-with-libraries-3.1.0.tar.xz file, but choose to not merge it in the branch. But to get this properly reviewed and committed to master instead (so for 3.2 we can generate this more automatically).

This was a temp hack to get the release out of the way, it did it's job, but honestly, i'm not super thrilled about the dependency between the deps builder and the blender cmake macro's, the builder may live in the blender repo, but i still see the builder as a standalone project (it used to be before it was absorbed into the blender tree) and shouldn't be concerned with figuring out the version of a project independent from it.

personally i feel the way to go here is

1. In the builder have

set(PACKAGE_REPOSITORY "https://svn.blender.org/svnroot/bf-blender/trunk/lib/packages/" CACHE STRING "Location of the package repository")
and not worry about trying to figure out where in the release cycle we are or other "smart things"

2. if any of our make helpers want to do something smart they can figure-out what they want and pass a -DPACKAGE_REPOSITORY="https://anywhere,you.want.it.to.be.org/" to it's cmake invocation

What if ... we simply change the URL the moment we branch out (bcon3), and in the branch?

So while in master we keep:

set(TARGET_URI  https://svn.blender.org/svnroot/bf-blender/trunk/lib/packages/${TARGET_FILE})

When we branch out we can do:

set(TARGET_URI  https://svn.blender.org/svnroot/bf-blender/tags/blender-3.2-release/lib/packages/${TARGET_FILE})

I'm surprised I didn't think about this earlier since it is by far the simplest option. But I'm glad we can visit this with fresh eyes without the release rush.

In D14292#383936, @Dalai Felinto (dfelinto) wrote:

What if ... we simply change the URL the moment we branch out (bcon3), and in the branch?

That LGTM. Is there a script that's used for branching out, which can be updated for this? I wouldn't trust a manual checklist for this, it's too easy to miss a step.

There is no script, but a very granular checklist followed by the release team. I think it is good enough this way. And worst case scenario we will have a make source_archive_complete fail.

@Ray Molenkamp (LazyDodo) thoughts?

No complaints from me, personally I'm a huge fan of checklists being actually completed, have a page on the wiki somewhere or a ticket with the checklist for something, and have people place actual check marks in tasks they complete, that's how I run the lib updates, (ie 3.0 update, 3.1 update , 3.2 update) easy for me to see the state of things, easy for others to see the state of things.

In D14292#383936, @Dalai Felinto (dfelinto) wrote:

What if ... we simply change the URL the moment we branch out (bcon3), and in the branch?

In D14292#384546, @Ray Molenkamp (LazyDodo) wrote:

No complaints from me, personally I'm a huge fan of checklists being actually completed, have a page on the wiki somewhere or a ticket with the checklist for something, and have people place actual check marks in tasks they complete, that's how I run the lib updates, (ie 3.0 update, 3.1 update , 3.2 update) easy for me to see the state of things, easy for others to see the state of things.

I'm convinced, that approach LGTM.

Updated https://wiki.blender.org/wiki/Process/Release_Checklist#III_-_After_Branching

Committed on rB643da14a4efd6a0eeb9ed21dd68643fdc7a6359e .