torewave.blogg.se

1. #Running multiple copies of blender software software
2. #Running multiple copies of blender software code

Make sure the program has a version label "1.0" somewhere inside and writes this version somewhere into the set of output files, so you can always find out from which version the output was produced. When you have "version 1.0" with algorithm A ready, "release it" (that may simply mean to copy all executable files over to a "production 1.0" folder, nothing complicated, in Python I guess this is mostly identical with the source code). The second approach is most effective when you only want to maintain the "latest and the greatest" version of the code, but to run the different versions in parallel, you should establish a proper versioning and release process. To make this possible, writing automated regression tests is usually a must. Hence, it is important to refactor constantly any commonalities between the algorithms into shared classes, sticking to the DRY principle, otherwise one will undoubtly run into a maintenance nightmare. The drawback is that it becomes moree challenging in regards to maintenance and evolvement, since it will require more effort to maintain all the algorithm variants over time. It gives you the possibility to maintain and evolve A, B and C in parallel, fix bugs and add improvements like user interface extensions, logging, improved error handling and other new featuers to the program to all of them over time. The first approach makes it easier to switch between all the available algorithms at runtime (by some parameter, like a command line parameter). You need to clarify first if you wantĪ, B, C all in the same version of your program (version like "version 3.0", for example), each one available side-by-side with the other algorithms, orĪ in version 1.0, B only in version 2.0 and C only available in version 3.0 From that, I think I can give you some hints.įirst, let us call "A, B and C" different algorithms for solving the same problem.

#Running multiple copies of blender software software

Having written a lot of computational software by myself, I have been in your shoes several times. It would be easier to read if I had a version with just the A code. So I'd have one class, but I'd specify if I want the A or B (or C) logic. I have seen suggestions for feature flags. In those cases I would default to an earlier version for a quick-and-dirty answers.

For some purposes I may prefer a faster answer, even if it were less accurate. Each version is intended to offer an incremental improvement in forecasting accuracy, although this will typically require greater complexity and processing. In the future I'd start on version C, and I'd like to be able to test C alongside B (and maybe A).

Version B ought to give more accurate results (and if not it needs improved/fixed). To test the new changes, I'd like to run a test data set through both version A and version B.

#Running multiple copies of blender software code

I want to be able to run both of these versions of code at the same time in at least these two situations: (It's a forecasting model in Python, but my question is perhaps broader than either of those things.) I have a stable version A of my code, and am working on some accuracy improvements for version B. How should I set up my project when I want to run the present version of a class against previous versions? I'm interested in issues related to code organization, file naming, and source control.