New extversion release

Marko has release a new beta of the extversion project on os4depot.

http://os4depot.net/index.php?functio ... lity/shell/extversion.lha

Please help him test the binary so that he can work towards sending this project to Hyperion.

Sorry for lame question (as probably was asked few times already), but did it will be "extversion" binary which will be in C: by default ? If so, imho than not so nice to have 2 different binaries (vesion and extversion) for about the same purposes. Probably it should be just 1 binary "version" as it now, just with functionaly of old version strings, and new "ext" ones. Or i miss the moment, and it will be exactly like this and code of extversion will be just added to the "version" code, and when user will do "version something" there will be and usual VER and EXTVER if present ?

But then, why we just can't use VER as before, i mean add the same as was done before in software coder working on, or there is some moments which i miss again and there is needs for EXTVER ?

@kas1e

Well, wheather Version and Extversion will be merged into one binary or use two binaries is, at the end of the day, up to Hyperion as I understand it. :)

I'm more concended about the $EXTVER: cookie (data format) right now :S
It has data redundancy, almost all entries in $EXTVER: are duplicates of the ones in $VER: except of one entry, easier to make mistakes when duplicating the fields and so on (not so optimal IMHO)..

But one binary or two binaries, I can keep that in mind when adding/implementing options and stuff. And try to make it easier whether there will be a merge or not.

@kas1e

Quote:

You can use the $VER: as before, the $EXTVER: is just a complement to $VER:.

So you may use $VER:

or

both $VER: and $EXTVER:

as it looks right now.

$EXTVER: Is meant for if you want to add a non-amiga-version-string (like beta2 or 1.05rc3) in addition to the normal amiga-version.

Right now I have followed the "specification" for Extversion given on OpenAmiga.org. I don't know if there has been any talk on some thread about the format in the Extver cookie, or if it has been decided by Hyperion already. But I'm pondering on making some changes in that area to make it easier whether extversion will be just a complement or a replacement to/for the $VER: cookie...

So, the normal version cookie looks like this:
Quote:

The Extversion cookie looks like this (at the moment)
Quote:

So the thing I'm pondering on right now, to make the $EXTVER: cookie "fit/adaptable" to both cases depending on if Hyperion decides to use it as a complement or a replacement is:

Quote:

In the above cookie, a slight change in $EXTVER: cookie. It's just as the version cookie but the nonamigaversion field has been added at position where the comment is, and the comment is moved one step further.

* This has also data redundancy as the original $EXTVER: cookie, but it supports both amiga-version-numbers and non-amiga-version-strings.
* And fits better whether Hyperion wants to replace $VER: with it or not.
* And makes it easier for developers also since it looks almost the same as the $VER: cookie except the non-amiga-version field is placed where the comment field would have been on a normal VERSION cookie.
* And it seems some devs already writes the non-amiga-version-string in the comments section anyway.

And also a shorter $EXTVER: cookie with much less data redundancy, making it more fit if $EXTVER: will be just a complement. It is assumed that the other info is in the normal VERSION cookie already.
Quote:

I think there will not be any bigger issues codewise to support both the altered and the shorter $EXTVER: cookie. Depends on if the "specification" is already set in stone (by Hyperion/the users/devs/?) or if it's open for alterations...

What do you think?

Keep the $EXTVER: as it is (option 1), or go for the slighly altered $EXTVER: and the shorter $EXTVER: to make it "more fit" (option 2)?

If you're replacing $VER with $EXTVER I'd suggest to rename it as $VERS or something of that ilk.

@Chris

$EXTVER: Is not a replacement (yet, but in case if in the future)...

But from your reply I take it that you are suggesting option 2 right thanks

To be honest I don't see the need for a new cookie at all. Just add the non amiga version in the existing comment of the $VER string.

Perhaps you could use a TAB as a delimeter, that way old version would see just the comment as a whole, new extversion could split the comment at the TAB.

In fact you could *require* the tab for it to be an extversion.

"\0$VER programname version.revision (dd.mm.yyyy) nonamigaversion\tcomment\0"

@broadblues

Yes, something like that would be possible too, thanks :)

But I take it that you're suggesting option 2 as well...

PS: $EXTVER: is not a requirement, it's just optional.

As being the one who created the project.

EXTVER is _NOT_ a replacement to VER. It's solely intended as a complement to VER.

All of this is described in a very simple language that most people should be able to understand on the project page.

Hyperion has deemed this project, as it is currently defined, to be of HIGH priority.

Any redefinition of the regular $VER cookie is NOT part of this project.

Including the Amiga version in the $EXTVER cookie is NOT part of this project.

Any other cookie definition like $VERS or whatever is NOT part of this project.

If someone wants to include any of those three then that would have to be a separate, non official, project not related to either hyperion nor openamiga.

An acceptable alternate solution is to create a replacement "version" command where you can specify if it's the Extversion you're interested in as a new command line parameter. That is, it would be able to handle both cookies.

@orgin

Ok, thanks for the info. I stick to option 1, following the specification (on OpenAmiga.org) fully as I have done already.

Quote:

Yep, that should be possible, added to TODO list :)

@Marko

The original version command might have some sanity checks like being able to handle two digit years and such. And there might be other quirks it handles as well. Though without the original source it's hard to know what those sanity checks might be.

Perhaps you can check with ssolie or rigo for pointers if you go for a replacement command.

Yep, that's something to consider. I'll make it fully working with Extver first, before/then if going to stage 2 (replacement), I can check with ssolie or rigo for pointers, thanks... :)

@Marko

The Version command is quite a complex beast, as I understand it, probably better to let the OS4 team merge your functionality into it, if they so desire, than to attempt a replacement function with dual functionality.

@broadblues

Yes noted, thanks :) I'll make fully working with Extver before anything else, then we'll see, we take from there...

@Marko

I don't get it, what stops anyone from adding the $EXTVER stuff on a new line in $VER

what the point of doing:

static const char ver[] = “VER$ amiga prog 1.1 (dd.m.yyyy)“;
static const char extver[] = “EXTVER$ Linux ver 1.1.1“;

vs doing:

static const char *var “VER$ amiga prog 1.1 (dd.m.yyyy)\nLinux ver 1.1.1“;

@Marko

Might be best to not allow two digit years for the extver if that was what you were referring to, let's not invite more quirks than we need to. Better to have a strict and well known format.

@orgin

Ok, two digit years removed (for now)