From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, LOTS_OF_MONEY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5894fe67040038b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-07 11:43:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Attributes 'Version and 'Body_Version Date: Wed, 7 Nov 2001 14:00:30 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9sc0cf$76a$1@nh.pace.co.uk> References: <9s9iti$g$1@nh.pace.co.uk> <5ee5b646.0111061939.595b61be@posting.google.com> <9sbb1f$2bm$1@plutonium.btinternet.com> <9sboee$42f$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1005159631 7370 136.170.200.133 (7 Nov 2001 19:00:31 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 7 Nov 2001 19:00:31 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:16012 Date: 2001-11-07T19:00:31+00:00 List-Id: O.K. You can get there from here. Sort of. If you dutifully record every version string of a released component you at least know the valid history and you can check against it. But I still think this is not as useful. Example: package Somepackage is -- Version 1.0 (my number) A, B, C : Integer ; end Somepackage ; package Somepackage is -- Version 2.0 (my number) A, B, C : Integer ; D, E, F : Integer ; end Somepackage ; So assuming I know something about when features are introduced and that my project (attempts to) maintain upward compatibility and all that, what, if anything, might I know about Version 1.5? If I know that D, E and F were introduced in 2.0 and my calling module detects 2.0 *or greater* then it is O.K. to use D, E and F. If it sees a module that is *less than* 2.0, it knows not to use D, E and F. If, for some reason, a 1.5 version were to exist out there, I'd know by the order that it wasn't compatible. Granted, this is a contrived example and the compiler would catch any invalid use of D E and F (thank you, Ada.) But one can easily imagine cases that are more complex in which an ordered version string would help. It isn't a perfect thing and it isn't a substitute for good configuration management and knowing what is going on with one's software, but I could imagine situations where this might be helpful if it were ordered. You can always Roll Your Own and this may, in some circumstances, be a better idea. (What causes the 'Version or 'Body_Version to be incremented? Every time you edit the file? Every time you compile it? Every time there is some semantic difference? What if you revert to a prior version of the file? What if you need to be compiler-independent? Etc?) The weaknesses of 'Version & 'Body_Version may make it impractical for some uses - but making it Ordinal would probably have been a good thing. (Any reason *not* to make it Ordinal?) MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Vincent Marciante" wrote in message news:W4fG7.11237$ym4.493547@iad-read.news.verio.net... > > But you do know the order order of earlier versions and can store that list > in each new version othe code. You also know that any version that was > not a past version (not in the stored list) must be a new version and can > then > deside what to do in that case (this case will only come up when a past > version of the code is attempting to work with a newer version ) >