the traits of this problem resemble the deisgn of a method known as a
hierachical database. That type of a form is used for static information,
which comes in levels of authority.
President-
- Marketing/Chief Technology Offier/Human Resources
- Assistant 1, Assistant 2
- where the dashes separate the levels of authority.
In the case we are considering, the first levels are your modules, or what
is known as program space.. That would be a term used by Biedler in his
book PowerBuilder 4 Adv. Techniques. He considers execution style, data,
essential factors (variables) that govern the program section.
You might want to use interger math, or floating point, in two versions of
the same module for exemple.
The structures work outr like C language structures or typedefs., in that
one structure can include some subtypes. thos would be your sub version
issues like fixes, or type of program modifier.
Create the problem before solving it. And then don't worry about it.
"Logan Shaw" <lshaw-usenet@[EMAIL PROTECTED]
> wrote in message
news:4823c8cb$0$3386$4c368faf@[EMAIL PROTECTED]
> James Harris wrote:
> > Is there any mileage in devising a general application version
> > numbering scheme and providing sup****t this in a programming language?
> > The reason for asking is that it seems useful, in terms of managing a
> > computer system composed of many modules, for the components of that
> > system to have at least
> >
> > <user version info>.<feature>.<fix>
> >
> > where
> >
> > <feature> increments on each /release/ of a new feature set
> > <fix> resets to 0 or 1 on each feature change and increments on
> > each released bug-fix
> >
> > The user version info would be arbitrary so could include higher level
> > version numbers or not as needed. For example, MyApp.2.1.4 would be a
> > release of "MyApp.2" feature set 1 and fix version 4.
> >
> > Why offer sup****t for this in a programming language? For two reasons,
> > 1. it provides intrinsic sup****t for releases of standard (and
> > possibly other) libraries for the language; 2. it offers this sup****t
> > to applications (and system programs) written in the language. These
> > are only worth doing if the scheme is general enough.
>
> IMHO, no scheme is likely to be general enough that having a single
> scheme is sufficient most of the time. No matter what assumption you
> make about release cycles (and relation****ps that "always" hold between
> one release and another), your assumption will ultimately be violated
> eventually (and then your model will break).
>
> I think what I'm saying is that programming languages are so general
> (or should be so general) that trying to solve this problem in the
> programming language seems like a bad idea. Ultimately, it's the
> environment and cir***stances of an individual application (or
> "project", whatever term you want to use) that determine the needs
> for a scheme for naming releases. And hopefully a programming language
> is general enough to be used for multiple different types of
applications
> with different needs! (Well, ignoring domain-specific languages.)
>
> To make that a little more concrete, some complications you might
> see are:
>
> 1) Some applications might not choose to define a total ordering
> of version numbers. It's simpler to comprehend if all development
> proceeds along a single line, always marching forward towards the
> end-state of perfection. But in reality, customer A demands an
> immediate fix for bug 1 and customer B doesn't care about bug 1
> but does demand an immediate fix for bug 2. Fixes for bugs 1
> and 2 go into version N+1, but there is no inherent ordering
> between bug fix 1 and 2. You can ignore this issue by speaking
> of only "official" releases, thereby forcing everything into a
> nice linear sequence of releases, and maybe that's all that you
> care about. But whether you want to force everything into a
> single sequence is something that depends on the software.
> For example, some software is developed without any customers
> in mind, and in that case, a linear model is easy enough to
> maintain.
>
> 2) The semantics of the actual version number vary between one
> piece of software and another. In the standard Linux-inspired
> versioning scheme, versions are a list of numbers, and there is
> some number in the list which has a special status so that odd
> numbers mean "unstable" and even numbers mean "stable". For
> example, in the Linux world, kernel version 2.6.25.2 is
> (nominally) stable, but version 2.5.x is not. The difference
> lies in the fact that *second* number is odd. Of course,
> it would be just as valid for some other project to define
> 8.x as stable (because 8 is even) and 9.x as unstable (because
> 9 is odd. To put this a different way, every project has a
> function mapping version numbers to meanings, and that
> function tends to be different for different projects.
> The reason this is significant (to me) is that the ability
> to manipulate version numbers (other than as opaque strings)
> rests largely on being able to assign meaning to different ones.
>
> Because of all this, if one were to try to "solve" the version
> numbers problem (and I use quotation marks because I don't know
> if it is ultimately solvable in the general case), there would
> be a lot of custom, per-application behavior required. Therefore,
> it seems like trying to move this into the language is probably
> a bad idea, unless it is done in a very general manner. And
> by "general", I mean allowing the individual application to define
> relations between version numbers ("X is more stable than Y",
> or "A has more features than B", or even "C is the freeware
> version of "D"), allowing the rules to change over time, and so on.
>
> - Logan
>
> P.S.: On the other hand, there can be some value in a language
> providing direction and forcing 95% of the applications
> into a certain mold. At least insofar as the applications
> don't have any strong preference of their own.
|
