Object versioning requirements

My recent screw-up of having an older version of Float32 in my work directory (don't know how it got there) preempting the newer one in the lib directory got me thinking about version specifications for objects. Right now, version numbering in the OBEX is a free-for-all: each contributor has his own system, and even those may not be adhered to. For the OBEX to function effectively, I believe that Spin needs a VER section that accepts a single, standardized version number (e.g. 1.2.0) with a well-defined order (e.g. 1.3.0 > 1.2.9). Then, in the OBJ section, the user can specify the version required by his code, if it matters. For example:
You get the idea. That way, version dependencies, if they exist, can be factored into the Propeller Tool's search process for the correct object.
BTW, this suggestion is not meant in any way as a substitute for subdirectory specs in the OBJ section. I still consider that to be priority one for the next version of the Propeller Tool.
-Phil
OBJ
sio : "FullDuplexSerial" (1.2.0) 'Version 1.2.0 only.
sio : "FullDuplexSerial" (1.2) 'Any version 1.2 variant.
sio : "FullDuplexSerial" (2 ..) 'Any version 2 variant, or higher.
sio : "FullDuplexSerial" (1.2 .. 1.4) 'Any version 1.2 to 1.4 variant.
You get the idea. That way, version dependencies, if they exist, can be factored into the Propeller Tool's search process for the correct object.
BTW, this suggestion is not meant in any way as a substitute for subdirectory specs in the OBJ section. I still consider that to be priority one for the next version of the Propeller Tool.
-Phil
Comments
I totally agree. I have the same problem. I think a while back I had the same situation with the float object as you. I couldn't ever figure out what was going on (I never trust my own code), so I just went with a different solution.
I would like to see some kind of revision notation in the files to keep things straight.
I really need to go through my library and clean it out, and start all over. I have some many different versions, I don't even know where to begin.
James L
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer
Lil Brother SMT Assembly Services
Are you addicted to technology or Micro-controllers..... then checkout the forums at Savage Circuits. Learn to build your own Gizmos!
The simple alternative would be to make the version number part of the filename. It would be easier to parse through filenames caught with wildcards than having to open each file and parse its contents.
When it comes to final compiled code, I don't know if I'd want to rely on a range of versions, but would rather specify, exactly, which object to use, and then test it for confidence.
It would be neat if the file system could handle this for you, pulling the issue out of the tool and making it part of the way files are selected, once a name is specified.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Sub directory for objects/projects - oh please, please, please, please allow for sub directories for objects. I wish I could 'clean up' some of my larger projects by putting objects in subdirectories.
Also I wish the pull down list on the left for folder shortcuts could be customized.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
Having a common method both for appending the filename and accessing version details would be good.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
CON VERSION_1_0_2 = true VERSION_1_0_3 = true
That way, if you specify a certain version that 's not defined in (i.e. compatible with) the object (e.g. Object#VERSION_1_0_4), the compiler will catch it and flag the error, and you won't have to wait for the program to run. Also, if conditional compilation is ever implemented, a simple #ifdef would give you options to take corrective action during compilation. Nope, scratch that: by then it's too late, since you've already spec'd the OBJect. Dang!
-Phil
I was thinking that the version numbers be text readable and that a binary capabilities mask be used as well. So for instance "this serial object supports RS485" and so on.
Using BST rather than the Prop tool we can catch incompatibilities at compile time using the conditional directives to bomb the compiler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
If, for some reason I want to keep old object versions around what I generally do is symlink the latest version to an object called _CURRENT and reference that. That way I know I'm always getting the current object.
I've been pretty strict about including the version number in the object name so I've not really found this stuff to be a problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.