Is there any mileage in devising a general application version
numbering scheme and providing support 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 support for this in a programming language? For two reasons,
1. it provides intrinsic support for releases of standard (and
possibly other) libraries for the language; 2. it offers this support
to applications (and system programs) written in the language. These
are only worth doing if the scheme is general enough.

Note that use of the scheme would be optional for apps and system
programs, and strictly speaking optional for libraries too. I'm not
proposing mandating use of this feature, just asking if it would be
useful and if there is a better way to arrange releases of code.

--
James

On May 8, 7:57*pm, James Harris <james.harri...@googlemail.com> wrote:
Perl has something like this. http://perldoc.perl.org/functions/use.html

James Harris wrote:
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 relationships 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 circumstances 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.

I find what is above all so interesting. A comment, that from a view from
systems analysis the scheme of versioning is proposed as a process or a view
of a process, and should be approached as a mid-level management tactic, as
processes are known to be. The versionsing scheme is not strictly physical
manipulation, or long range goal setting, but a mid-level work.

From what I am doing, I can refer to the issue of feasiblity (in operations
terms) and ask if this is a problem which is worth the expense of solving.
It certainly is, but this is an update which either finds fault with earlier
versioning or has to expand upon it. From there you just want o look at
what the nature of the actual problem is. Then a model of the tasks and
operations which will ultimately adopt your process is set down,

In ths framework of the real world user, I have heard that many parts of a
single program are generally assembled into a system such as an MIS, or MSS
(support system).

I conclude that it is a prototype issue, that you seem to be raising and
thatyou might want to linkk your versioning to other files, such as studies
of users, and platforms. Now have a hard rum in a can, and give em heck
harry...

"Logan Shaw" <lshaw-usenet@austin.rr.com> wrote in message
news:4823c8cb$0$3386$4c368faf@roadrunner.com...

On 9 May, 04:48, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
....
Agreed. It's not possible to please everyone all the time with one
scheme. However, would it make the work of us programmers easier if
there was standard versioning info provided in the language?
Versioning, while not normally a language feature, is an intrinsic
part of what we do with the programming languages so maybe it should
be included.

To be more specific I am thinking of my language being used for
writing many small reusable modules which are effectively linked at
load time rather than being linked into a large monolithic executable.
Of course, this is not a new concept but because modules call each
other the caller needs to be confident that the callee can service the
request adequately. For that it may need to say, call module Fred but
make sure it is at least version 5 since lower versions of Fred do not
contain the feature I need.

We face this situation many times while developing code. For example,
Windows application A needs version V or above of MS Windows and will
not run on a lower version because Windows version V has a feature on
which A depends.

We sometimes want a feature that we know was present in version V but
was buggy until release V.R so we want to use V.R or above. My simple
scheme struggles a little if we have version (V + 1) available but
don't know which release of (V + 1) has had the bug fixed. If we know,
then we can specify we require either V.R1 or (V + 1).R2 etc.

Good points especially about there being no inherent ordering between
bug fixes in some cases. Sounds like the customers would each get
their own fixes. Maybe the bug fixes for both customers could be
incorporated in the next general bug-fix release.

True. I was thinking that in the scheme

<name>.<feature>.<fix>

that the name would be different for development and production code.
Basically, for the development code the feature and fix numbers could
get very large very rapidly as the code is improved but that the
production code feature and fix numbers would increment slowly as new
releases are made. For example, development version MyAppDev.45.70
could become MyApp.3.0. The two versions of code would be identical,
only the name and version numbers would differ. Why? Because MyAppDev.
45.70 would have had 70 bug fixes before it was certified bug free and
suitable for release. Once it has been verified as suitable then it is
migrated and released as MyApp.3.0.

Maybe my scheme is not the best (almost certainly and I would welcome
improvement) but having the concept/structure within the language
would allow developers to work to a common scheme if they wished to do
so. It would help greatly if developers tended to use a common scheme
so we don't have to remember, for example, that the Linux kernel uses
scheme X and each of its apps uses a different scheme (possibly each
app uses its own scheme which just adds to the confusion).

If only the supplied versioning can be made general enough then I
believe many programmers would use it. I did think of having a simple
build number but that is maybe too blunt an instrument. Not sure. At
any rate, I think of a build version as one-dimensional while a
feature/fix arrangement is two-dimensional. Maybe even that is too
blunt in some cases. At the end of the day the idea is to allow code
that we write as programmers to put constraints on which modules we
call.

I'm sure it is as you say and is not generally solvable but if it
could be made sufficiently general that should reduce the custom code
shouldn't it? It is true that even if we could come up with a perfect
scheme now someone would come up with a better one later. That said,
if we can devise a sufficiently general scheme it may last some time
and be useful to programmers.

You raise some interesting categories. Would you agree that we need to
be specific? "More stable than" is too vague. "More features than"
needs, I suggest, to be, "has specific feature(s)." The freeware one
is interesting. Maybe we need to list what 'components' could be
needed to make up a version string. Taking it right back to the vendor
to make each version name unique we could use

Vendor
Library or other grouping as chosen by vendor
Library version (perhaps)
Program - i.e. name of app or function
Train - production differs from development releases
Feature set - the traditional version number, perhaps
Bug fix

For an example of a large program, Microsoft Word: Vendor =
com.microsoft (using reverse DNS for canonical uniqueness), library/
group = Office, program = Word, train = production (the production
release would have no suffix but the many development versions would
have), then feature set and bug fix numbers as above.

For an example of a small program, Heath Robinson's super duper
increment by one: Vendor = com.heath-robinson, library/group =
PublicUtilities, program = Increment, train = production, then feature
and fix numbers.

These should uniquely identify any piece of published code. The
feature and fix numbers are the only components that the linker should
be able to adjust when finding a called module, i.e. it would look for
a callee with numbers at least as good as those requested.

True. And consider the alternative of not providing versioning. In
that case each program (unless fully linked) would need specific code
to check it was calling suitable code in libraries. It seems daft for
each program to carry out the same checking in its own way if a
general scheme can be provided.

Anyone have a better solution than my feature/fix scheme?

--
James

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@austin.rr.com> wrote in message
news:4823c8cb$0$3386$4c368faf@roadrunner.com...

James Harris wrote:
If I had time, I'd comment on some of the other stuff you said because
it was interesting, but I just wanted to throw another idea out there,
even though it may not be practical:

What about the concept of multiple version number schemes, with the
ability for each piece of software to specify which one it uses?
You could have, say, a scheme called "simple", which is just a
string of period-separated non-negative integers and which has
full-ordering and no other semantics; a scheme called "linux-style",
which is like "simple" but which defines one position whose oddness
or evenness indicates whether it's stable; a scheme called "date",
for software that is tracked only based on the date of release;
and so on.

This could even be done with an object-oriented approach, so that
these schemes are in a class hierarchy. That presents some
complications (like how to make the code that implements the classes
accessible when it's needed!), but it would be nice to be able to
define a custom version number scheme for a piece of software.

On yet another tangent, what about the idea of leaving version numbers
mostly how they are, then defining something you might call a "release
descriptor"? You could encode properties of the software into the
release descriptor. Features and bugfixes could have identifiers and
those identifiers could exist in a feature list and bugfix list in the
release descriptor. Everybody expects version numbers to be pretty
concise, so by using something else entirely, you can avoid that
constraint and encode more useful information.

So for example, version 1.0 of app "MyHttpLib" is released, and it
has the ability to fetch URLs with HTTP. So it gets a release
descriptor that looks something like this:

version = "1.0"
features = [fetch_by_http]
bugfixes = []

A bug is discovered where it dies if the file being fetched is too
large. Version 1.1 fixes that bug and adds the ability to fetch
with HTTPS, so its release descriptor looks like this:

version = "1.1"
features = [fetch_by_http, fetch_by_https]
bugfixes = [large_files_death]

Essentially, it would be nice if a lot (not all) of the information
that gets specified in a README file or in release notes could get
captured in a machine-readable format. Especially if there were an
API available to programatically access it from application code.

Taking the above example, imagine you've written a web browser that
uses MyHttpLib. You've coded a workaround for the bug large_files_death,
but if the bug were fixed, you'd prefer not to use your workaround
because the workaround creates performance problems. At present,
that code almost always looks like:

int maxFetch = -1;
if (MyHttpLib.getVersion() <= X.Y.Z) {
maxFetch = 10000;
}

This is not usually easy to maintain because later on it's not so
easy to see what the intention is. And worse, it's not even always
right, because there are a lot of ad hoc routines to compare version
numbers based on incomplete research about which versions have the
bug fix and which don't. :-)

Of course, there might be other properties that are useful as well,
like whether the release (or build) is a development release, and
so on.

One could even take this a little further and build a comprehensive
version history data structure for a given app, so that client code
could take the latest version history and find out new information
that wasn't captured in an app's then-current release descriptor.
Like that versions 1.2 through 1.5 of some software have a security
flaw, but version 1.1 and early don't suffer from it.

Looking back on the above, it sorta looks like massive scope creep
on a simple idea to support manipulating version numbers. So take
it mostly as brainstorming about whether version numbers themselves
are the right place to encode that kind of information and what
kind of information would be useful to encode.

- Logan

The use of application development tools would be a portion of a
communication effort among a group of programmers. The application
development tools would provide useful templates that assist the goal of
uniformity throughout parts of the development system. Generic code can
provide functionality common to many application functions, as in the case
of loop statements, control statements etc. These are built-in constructs
provided by all programming languages, generically.

One of the most valuable benefits of object-oriented development is this
ability to share objects. A correctly built PowerBuilder application uses
the power of inheritace to minimize coding and to maximize efficiency. Then
sharing objects increases code reliability and interface consistency and
eases the task of code maintenance by reducing or eliminating the need for
duplicate code.

The most important foundation for the application is the requirement list of
the user or client.

Program Documentation
Documentation of the program project is a major trade-off that must be made
when writing software applications for a system environment. A reference
book An Introduction to Data Structures by John Beidler (Univ. of Scranton)
publ. Allyn and Bacon, Inc. 1982 pp. 5 "The most sophisticated program can
be almost worthless if it is not documented in such a way that others can
read and understand how the program functions. It is important to remember
that programs must be read by humans as well as by computers. In fact, the
biggest problems faced in software development is the modification of
programs." .. "A good measure of a well written program is this: A program
by its very existence changes its environment. It can provide new
information which in turn suggests further enhancements to the program. If
a program can be easily modified so that it can be changed to keep abreast
of its changing environment it is one of the best tests of the quality of
the original design of the program."

"One consideration which programmers must take into account during the
design of the program and implementation is the programmer's personal
resources. These include the human time which it takes to perform the
programming process, in addition to the computer time and the computers
required to encode, debug
and carry out the program. ... Yet speed or program efficiency should not be
used as excuses for writing programs that cannot be maintained, are
unreadable, or lack documentation, testing, etc.."

Program Measurement
An important part of simplifying the internal program design is separating
the physical details of how certain things are carried out from the logical
requirements of what is supposed to be accomplished. Once a program
exists, new questions arise. In particular, how well does a program use its
resources? What are the program's time and space requirements? Does the
program make efficient use of its resources? Which variables influence the
program's resources? What effects do these variables have upon the program
resources?

A space requirement refers to the internal memory and disk drive storage
space that is necessary to use the program. This is a requirement which is
the sum of the space for the program and the data space. The space
requirements for the program itself are related to a specific computer
system. Normally a program is written to function within a given
hardware/software environment.

A time requirement means the amount of time used by a program. This can be
thought of in relation to the central processor, the amount of "wall time"
(that is time measured by the clock on your wall), I/O time, etc.

The time and space required by a program depend upon:
- the actual hardware
- the algorithmic structure of the program
- the data processed by the program

With regard to the structure of algorithms, there are four considerations,
the three basic control constructs, and modularization, specifically:
1- sequencing of program steps (control construct)
2- loop control (control construct)
3- conditional code execution (control construct)
4- modularization (modularization)

Sequencing is the sum of the time for the individual steps in the sequence.

Loop control time depends upon the number of times when the loop must
execute, plus the hardware time involved

Conditonal execution relates to a particular section, or a group of sections
which will be executed. The execution time amounts to the time of each
sequence plus the hardware time of each sequence. see An Introduction to
Data Structures by John Beidler (Univ. of Scranton) pp. 17.


Time constraints are important where it comes to meeting the internal
schedule of the program execution. In some scenarios a particular step can
be allowed to time-out and the program execution resumes. Beidler provides
a notation which can be used to evaluate the time required to determine the
execution time for a program pp. 19-21. It involves the total of the time
required for sequencing, looping, and sections which are conditional, in
addition to subprograms and conditonal controls (which might include units
of time).

He adds that the data being processed can affect the time and space
requirements of the program. He considers three items:
1- The amount of data
2- The actual values of the data items
3- The organizaton of the data (is it ready for an orderly processor)

Amount of data affects the linear measure of time (how long) in terms of
reading the data.

Actual data values refers to an algorithm which is applied to the data or
the size of the numbers themselves. A multiplication by zero (0) will take
less time then, 3456 times 233. A complex loop will take longer.

The organization of data suggests how the data will be entered. Tape drives
are slower devices and take longer etc.

Beidler suggests pp. 22 finding a bound on the program execution time or the
most important variable of the timing equation. Then focus upon how the
program time changes as that variable gets larger. Using the structure of
the program and assuming that any sequence of instructions is bound by some
constant K, the timing result is based upon the number of these sequences.

A collection of counting methods can be used to approach the program timing
issue, by building prototypes that execute commonly used steps and
iterations. The loops can be counted (number of executions) using an
incrementing, counting variable every 100 iterations perhaps Beidler pp. 25.
And for sub loops they set up a MIN and MAX which will be averaged, and
added to the program time in proportion to terms of the conditional
execution.


Overall, the program timing depends upon the time of execution required by
any sub programs, plus the requirements for a main program section. Some
portions of time can be fixed by a standard unit time delay.


Some Logical Structures
This section is from reference book An Introduction to Data Structures by
John Beidler (Univ. of Scranton) Chapter 3 pp. 37. "This chapter represents
an intuitive description of several of the structures that are studied
(throughout). Actually most of these structures can be represented in many
ways, and the problem of choosing a structure and its appropriate
representation is really two distinct problems:

1- Selecting the appropriate structures to represent and solve a problem
2- Selecting the appropriate representation of the structure to fit into the
problem's solution and resources.


The structure of a problem and the structures that lead to an efficient
solution can sometimes defy the clarity needed to understand them. A
structure in a software program or in data, refers to both a real structure
(in the computer) and the applied structure, how it is used. When asked to
state the structure of a building, a college, or a corporation the issues
are presented from observers points of view. The applied structure, how it
is used becomes one of access and utilization. see An Introduction to Data
Structures by John Beidler (Univ. of Scranton) pp.2.

"As essential data structure techniques are attempted, the importance of
good programming practices become more apparent. In particular, by
carefully studying the logical requirements of a program, and working out
the logical requirements before generating the code, many potential
difficulties will be bypassed. If more time is spent understanding a program
and designing the logical requirements of an algorithm, then less time will
be spent patching and debugging an inapproproate program."

The book An Introduction to Data Structures by John Beidler (Univ. of
Scranton) proceeds to chapter 2 where a discussion about program
measurement is developed. "Basically, given a computer system, a program
has two resources, time and space, whose usage is affected by three
factors - (1) hardware, (2) the algorithm, and (3) the data...

Structured programming assists the programmer with the question on how well
does a program use its resources?. Which variables influence the program's
resources. The section considers the effects of the algorithm, and the data
upon the program's timing. Hardware is considered but I see the hardware as
being beyond what I can worry about.

There is no complete and exhaustive collection of program measurement
techniques. Program measurement can be difficult and sometimes impossible.
Basic techniques of measuring a program's time requirement and methods of
recognizing certan recurring timing situations are available. Space
requirements can be described using these techniques as well An Introduction
to Data Structures by John Beidler (Univ. of Scranton) pp. 15.




Space and Time Measurement





For the most part the preliminary interest would be to use Access data
storage in connection with other Microsoft data sharing applications. This
type of office automation and data sharing will occur often with the use of
LAN network technology within an organization. We note below that office
automation is one of the five (5) application types which are used as broad
categories.

The types of applications are five (5) computer-based application areas
which are (1) expert systems (ES), (2) management information systems (MIS),
(3) decision support systems (DSS), (4) office automation (OA). Office
automation includes -word processing, video conferencing, email, electronic
calendaring, facsimile transmision, and desktop publishing, etc. (5)
accounting information systems (AIS).

Each of these 5 application areas expert systems, MIS, DSS, OA, and AIS
represents a subsystem within an application which is dedicated to using
information produced among the these components (data integration), and
dedicates those results produced to the higher-level problem solving
application.


Programming may have generally been the only way to access and manipulate a
database from within another application, but some other programming books
are around for the purposes of comparison and alternatives to the reference
we use, "Excel VBA Programming" book, authored by Duane Birnbaum. The
practice of database programming is not an original thought from VBA and
Microsoft. It occurs to me that OLE provides data movement between
applications. Data integration is a matter of using data which is
comparable, and is amenable to summing, and/or shared inputs and outputs.

He is suggesting that non-programmed GUI interfaces, that are also
programmed (some language other than VBA) are nothing new. His book is
about VBA and programming, which is how his comparison works. This
statement by Romans must include OLE, a part of the standard Microsoft GUI.

Romans says, "that database design, and database programing are not related
in the sense that knowledge of one leads directly to knowledge of the other,
they are defintely linked, by the simple fact that a power database user
needs to know something about both of these subjects in order to effectively
create, use, and maintain a database."

A good place to begin work with the development of prototypes would be to
reengineer some of the examples found in database or SQL books. A common
example gven insuch books would be the library catalog of books, or movie
actors and their movies. A good exercise would be to diagram the entities
of these databases, and otherwisse diagram the flow chart of that system
architecture (blueprint). At that point add new items to the diagram which
are could make useful add-ons to the design model. And then make a
prototype database which uses your new add-on, and test how it works.


Logical vs. Physical Structure



The Database Application GUI
"In fact, it might be said that creating and maintaining a database
application in Microsoft Access is done in three (3) broad steps -designing
the database, creating the basic graphical interface (i.e, setting up the
tables, queries, forms, and reports), and then getting the application to
perform in the desired way." Romans book Preface.


- designing the database
- creating the basic graphical interface (i.e, setting up the tables,
queries, forms, and reports)
- getting the application to perform in the desired way


The creation of the database application GUI is fairly straight forward,
since it is mostly a matter of becoming familiar with the relatively easy to
use Access graphical user interface. A dozen books with thousands of pages
are devoted to Microsoft Access.


Steven Roman does not discuss forms and reports which are used within
Microsoft Access. Neither will he discuss database security or replication
or client server issues involving multiple users. Roman has been able to
keep the book short by avoiding those three subjects.

- forms and reports
- database security
- replication
- client/server issues involving multiple users


"Gary D Man" <captntony@boatsandharbors.com> wrote in message
news:mIidnfXdKMYl37rVnZ2dnUVZ_g-dnZ2d@hbci.com...

Logan Shaw <lshaw-usenet@austin.rr.com> wrote:

Linux is more complicated than that now. There is no 2.7.* `unstable'
branch; instead, Linus periodically tags his `master' branch with a new
2.6.n version number; there is then a separate team which applies
bugfixes (usuall backported from the master or some other development
branch) to these releases. So really the three-digit Linus releases are
`unstable' and the four-digit stable-team releases are `stable' -- or at
least stabilizing.

So for Linux kernel releases, the rule is that X.Y.Z[.P] is stable iff

X.Y < 2.6 and Y is even, or X.Y >= 2.6 and P exists

If you want a version numbering system, with an order, which applies
fairly well to more or less everything (with some occasional
shoe-horning), see

http://www.debian.org/doc/debian-pol...ml#s-f-Version

-- [mdw]

On May 8, 7:57 pm, James Harris <james.harri...@googlemail.com> wrote:
The Curl programming language (http://developers.curl.com) supports
version number meta-data which is used to specify the API version of
Curl being used and which also can be used to select packages. Version
numbers are an arbitrary chain of positive integers separated by '.',
with a final '+' indicating that the number will match later versions.
For example,

1.2.3+ will match 1.2.3, 1.2.4, 1.2.3.4, but not 1.3.

This lets you express a dependency on a minimum patch level without
matching later potentially incompatible versions. You can use this
when importing a package by writing something like:

{import MY-PACKAGE, version = "1.2.3+"}

However, since Curl applications are usually not configured with
multiple versions of the same package, this feature is hardly ever
used in practice.

One important versioning feature that is used, are the mandatory curl
version heralds that must be put at the top of the main file for every
Curl applet, package, manifest or script, e.g.:

{curl 6.0 applet}

This specifies that the applet uses version 6.0 of the Curl API, which
includes the Curl language itself along with a large set of standard
libraries. This declaration is used to dispatch to the appropriate
implementation when there is more than one version of Curl installed,
or will generate an error if the appropriate version is not present.
You can also write:

{curl 6.0.1+ applet}

to specify that the 6.0 installation has been upgraded to at least
version 6.0.1, although this is rarely needed.

On 15 May, 15:53, cbcurl <cbc...@gmail.com> wrote:
....
Interesting. I have a plan to put the language version at the top of
source files something like

lversion <vers>

to express what the compiler needs to support in order to compile the
code that follows. But I see this as different from the versions of
libraries and other generated code.

On May 15, 4:08 pm, James Harris <james.harri...@googlemail.com>
wrote:
That makes sense. In our case, the language and many of the low-level
libraries are closely intertwined. For example, types are first-class
objects in Curl, so the packages containing the definitions of type
objects must be included, along with any packages they depend on and
so forth.
Of course, this scheme only extends to packages that are included in
the run-time-environment (which is actually quite extensive).

Another aspect of the Curl version herald is that it implicitly
imports a set of packages based on the version number and component
type, so that the above declaration will arrange for the contents of
the 6.0 version of the CURL.IMPLICIT.APPLET package to be imported.
The set of packages implicitly imported by applets includes graphics
and GUI packages that are not imported implicitly in a Curl package.
Thus, in Curl you don't have to do as much explicit importing of
standard packages as in some other languages.

Microsoft was doing a software project called Windows. The had versions
with those versioning numbers i.e. Windows 3.0 and Windows 3.1. I neveer
saw 3.0, but I can't figure that they had a 3.1 if there was not 3.0.

They had to change to names like Millenium, and Vista and NT. I think the
McDonalds went the other way. Now to get food you just say give me #4 and
supersize that . Then you get 2 fillets o' fish with tartar sauce and
fries, and a cold drink. Otherwise the ordering process results in an
exchange of fries, not sprite!!
Merry Xmas (now where did that X come from?) You can use a system for
versioning that starts with X. There was a TCP/IP standard was it X.25.
That look wrong.. I think here is a Z out there in the magazine world. The
version can be like C language, but that is already taken.

Bill Cosby has taken all of the the pudding and jello flavors. The human
genone is free if you want to download that, you can name parts of your work
for some part of the human anatomy. Those schemes can get a little long.
What I suggest is getting together with friends, and playing the game where
one person describes an object and uses pantomime. Sounds like "house" ..
Oh mouse ... yes its the progam with the mouse .. is it Windows???? Was
that Windows or French doors??



"Mark Wooding" <mdw@distorted.org.uk> wrote in message
news:slrng2lt2c.ihm.mdw@metalzone.distorted.org.uk ...

I'e got two words of advice for you, LICENSE PLATES .. Those are good for
versioning the modules, and each one is unique. In addition, you can have a
version of vanity plates. Now go have porkchops and red wine, and walk
around the block.

"Food Fighter" <chefofspaghetti@yahoo.com> wrote in message
news:1sydnY3d0LvKPbLVnZ2dnUVZ_q_inZ2d@hbci.com...

["Followup-To:" header set to comp.lang.misc.]
On 2008-05-18, Food Fighter <chefofspaghetti@yahoo.com> wrote:
No they hadn't. All these are still versioned (e.g. NT4=4.0, windows 2000=
NT5.0, XP=NT5.1, win2003=NT5.2, Vista=NT6.0, don't know what w2008 is, 6.1
probably, though vistasp1 is supposed to be roughly equal to w2008)

So do not confuse versioning with monikers you communicate to the outside.