During some of the recent proposals for the attribute socket changes, a few people were concerned about their existing files, and the time spent on creating training material. I hope to use this topic to clarify the situation.
Note that this is valid for any of the changes planned for geometry notes. Regardless of the solution implemented.
Simulation solvers will be integrated directly with Geometry Nodes. That will make geometry nodes 10x bigger, and something to last more than 10 years. If all the work done so far (barely 6 months) is to be considered as a prototype, so be it. It would still have been worth it as a step to get things right.
This was one of the mantras I was following during the nodes workshop. That allowed us to contemplate the most radical ideas without falling into a sunken cost fallacy.
Geometry Nodes was never announced as experimental, or a prototype. And the reason is simple. Geometry Nodes is and has always been production-ready. It is been used extensively in Sprite Fright, and sparsely in other commercial projects.
Every single one of its usecases made Geometry Nodes production ready from day 1 (from its second week actually). The system was built incrementally, making sure what it supports, it does well.
And it was tried and proved in a production every step of the way. This is the definition of production-ready I’m abiding to.
The fact that some aspects of its design may change is the compromise of the “agile” approach the team is using. Some of the solutions we found were only possible because of the exploration we did. Validated (or refuted) by the production use cases.
The alternative would have been to make one monolithic design and follow it blindly until the system was fully finished. The everything nodes project started a bit like this, and this was literally the main change we did when we pivoted it into geometry nodes.
If possible all the old files should be converted on file load without any loss. The resulting file may not be the one with the prettiest nodetree. But it should work like it used to.
If not possible, Blender 3 is the moment to do this change. Even if Blender 3.0 itself may have missing functionality compared to 2.93. Blender 2.93 LTS will be supported for 2 more years.
This is not a desirable effect, but it is a compromise I’m willing to make.
Another concern some people have is in regard to their training material. Any current knowledge is directly applicable to the new attribute changes. But the specific ways of achieving the same effects will improve.
All the Blender development is done in the public. There are basically no secrets. This works as a double-edged sword sometimes. People create tutorials about features that are only available in alpha builds. Things that may change until they are fully mature. This is not unique to Geometry Nodes.
One can wait until a series is complete and then produce their documentation. The LTS releases at the end of the Blender series (2.93 LTS, 3.7 LTS, 4.7 LTS) are perfect candidates for this.
However if you are covering the day-to-day development of features it comes with a toll. I can only recommend fellow book and tutorial writers to provide context to their audience about the development process of Blender.
Finally keep in mind that no disruptive change is done lightly and in disregard to its impacts.