Shop OBEX P1 Docs P2 Docs Learn Events
Object versioning requirements — Parallax Forums

Object versioning requirements

Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
edited 2009-12-16 00:54 in Propeller 1
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:

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

  • James LongJames Long Posts: 1,181
    edited 2009-12-15 19:25
    Phil,

    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!
  • cgraceycgracey Posts: 14,274
    edited 2009-12-15 21:49
    I like this idea, but maybe it's just asking for new headaches.

    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.
  • Timothy D. SwieterTimothy D. Swieter Posts: 1,613
    edited 2009-12-15 22:20
    My method has been to use file names to include version for objects, sort of like what Andre suggests in his Hydra book. I have created trouble for myself a couple times though by creating a new version in the directory with the old version and forgetting to update my calling file.

    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
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-12-15 22:33
    I find that I have a lot of customized objects which might be fine at the time but then it catches me out some other time $%#^&@!. Of course we could append the filename with version numbers but sometimes it's also good to have the current/best object as an "unversioned" filename. But there is no reason why the version numbers can't be declared as a constant so we access the object from the main method using object#version to test it for suitability.

    Having a common method both for appending the filename and accessing version details would be good.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-12-16 00:00
    Peter Jakacki said...
    But there is no reason why the version numbers can't be declared as a constant so we access the object from the main method using object#version to test it for suitability.
    That's a good idea! Expanding on that a bit would be to define multiple constants == true that contain the applicable/compatible version numbers in the constant names themselves, viz:

    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
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-12-16 00:44
    Phil Pilgrim (PhiPi) said... That's a good idea! Expanding on that a bit would be to define multiple constants == true that contain the applicable/compatible version numbers in the constant names themselves, viz:

    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

    tongue.gif nuttin it out hey?

    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*
  • BradCBradC Posts: 2,601
    edited 2009-12-16 00:54
    The main reason I used to have multiple versions of library objects lying around was so I could cut out bits I was not using. Now I don't have to as the compiler does it for me, so I stick with a pretty defined library directory. When I want to add or modify stuff for my own use I add _BKC_XXX to the object name (where XXX is the version number) and therefore I have to specify it specifically in the object reference.

    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.
Sign In or Register to comment.