On 9 May, 04:48, Logan Shaw <lshaw-use...@[EMAIL PROTECTED]
> 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 relation****ps that "always" hold between
> one release and another), your assumption will ultimately be violated
> eventually (and then your model will break).
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.
> 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.
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
incor****ated in the next general bug-fix release.
> 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.
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.
> 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.
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.
> 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.
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
|
