OpenLibrary(Name,Ver,Rev)

AmigaOS users can make feature requests in this forum.
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

OpenLibrary(Name,Ver,Rev)

Post by mritter0 »

I would like to see an updated OpenLibrary/OpenClass() with version and revision values.

OpenLibrary("MyLibrary.library",2,12);

This way when small updates are made, like glyph.class having the new calendar pop image added, there will be a slight bump in the revision. I will update to it; I asked for it. But if Joe Blow doesn't but he runs my program's new version, it will crash when tries to draw the new calendar glyph.

Or am I stuck with checking

LibBase->LibNode.lib_Version
LibBase->LibNode.lib_Revision

Just looking to make things a bit easier.
Workbench Explorer - A better way to browse drawers
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 181
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: OpenLibrary(Name,Ver,Rev)

Post by colinw »

In the include file; exec/libraries.h you will find the macro; LIB_IS_AT_LEAST(lib,vers,rev)
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

Re: OpenLibrary(Name,Ver,Rev)

Post by mritter0 »

Nice. Thanks.
Workbench Explorer - A better way to browse drawers
xenic
Posts: 1165
Joined: Sun Jun 19, 2011 12:06 am

Re: OpenLibrary(Name,Ver,Rev)

Post by xenic »

mritter0 wrote:I would like to see an updated OpenLibrary/OpenClass() with version and revision values.

OpenLibrary("MyLibrary.library",2,12);

This way when small updates are made, like glyph.class having the new calendar pop image added, there will be a slight bump in the revision. I will update to it; I asked for it. But if Joe Blow doesn't but he runs my program's new version, it will crash when tries to draw the new calendar glyph.

Or am I stuck with checking

LibBase->LibNode.lib_Version
LibBase->LibNode.lib_Revision

Just looking to make things a bit easier.
Actually, I think the version number should be bumped if the new library is not compatible with the old one. The revision number can be bumped for bugfixes and changes that don't change the operation of the library. That's why OpenLibrary() only needs to check the version. I don't know why some programmers are reluctant to increase version numbers. There's absolutely no reason why a library or program can't have a version number of 5280 for example.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
thomasrapp
Posts: 289
Joined: Sat Jun 18, 2011 11:22 pm

Re: OpenLibrary(Name,Ver,Rev)

Post by thomasrapp »

xenic wrote:Actually, I think the version number should be bumped if the new library is not compatible with the old one.
I couldn't agree more.
I don't know why some programmers are reluctant to increase version numbers. There's absolutely no reason why a library or program can't have a version number of 5280 for example.
The reasoning is as I've been told that version numbers of OS components should be aligned with each other and a new version number would need a new OS version which happens seldomly in times of AmiUpdate.
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 521
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: OpenLibrary(Name,Ver,Rev)

Post by LyleHaze »

xenic wrote: Actually, I think the version number should be bumped if the new library is not compatible with the old one. The revision number can be bumped for bugfixes and changes that don't change the operation of the library. That's why OpenLibrary() only needs to check the version. I don't know why some programmers are reluctant to increase version numbers. There's absolutely no reason why a library or program can't have a version number of 5280 for example.
It is my understanding that newer versions of library code are required to remain backward compatible. New features MAY be added as long as backward compatibility is not interfered with.

This is why OpenLibrary will succeeds if the library is AT LEAST as high as the version specified.

If successive versions were not compatible, you'd need to keep multiple copies of each library. This gets messy in a few different ways.
xenic
Posts: 1165
Joined: Sun Jun 19, 2011 12:06 am

Re: OpenLibrary(Name,Ver,Rev)

Post by xenic »

LyleHaze wrote: It is my understanding that newer versions of library code are required to remain backward compatible. New features MAY be added as long as backward compatibility is not interfered with.

This is why OpenLibrary will succeeds if the library is AT LEAST as high as the version specified.

If successive versions were not compatible, you'd need to keep multiple copies of each library. This gets messy in a few different ways.
I think I misstated my point. What I really meant was that if software depends on a new library and won't function properly with an older version of the library, the new library should have the version bumped. If new and old software will work with a new library, the revision can be bumped. If a library isn't backward compatible it should be renamed. I don't think there has ever been much of a problem with backward compatibility for Amiga shared libraries. However, I've got numerous versions of the same SOBJs sitting on my hard disk and don't know what version works with what application.
AmigaOne X1000 with 2GB memory - OS4.1 FE
User avatar
mritter0
Posts: 214
Joined: Mon Aug 25, 2014 9:41 pm
Location: Bettendorf, IA, USA

Re: OpenLibrary(Name,Ver,Rev)

Post by mritter0 »

I don't agree with library version matching the OS version. How many years has OS4.1 been around? Still a while for OS4.2. If you wrote a custom library for your program, then the two versions should match: program is V2.5, library is V2.5. Both being updated at the same time.

With AmiUpdate there is no real reason not to be constantly updating and releasing the libraries and classes. If people see Hyperion actively developing, then it will motivate people to start/keep programming. I don't want to wait months for the new glyph.image with the new calendar image to come out.

For system libraries, bump revision if does not affect anything else (bug fixes only). Bump revision (bigger bump like 53.23 to 53.50) for additions that don't affect original usage. Bump version for additions that do affect other features.

If the programmers report that the libs/classes are too old, and specify, "You need listbrowser.gadget V53.99", with good alerts to the user, they can fire up AmiUpdate and get what they need. Not go to OS4Depot or have to Google it. AmiUpdate must be current.
Workbench Explorer - A better way to browse drawers
User avatar
LyleHaze
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 521
Joined: Sat Jun 18, 2011 4:06 pm
Location: North Florida, near the Big Bend

Re: OpenLibrary(Name,Ver,Rev)

Post by LyleHaze »

mritter0 wrote:I don't agree with library version matching the OS version. How many years has OS4.1 been around? Still a while for OS4.2. If you wrote a custom library for your program, then the two versions should match: program is V2.5, library is V2.5. Both being updated at the same time.
Libraries are shared, intended to be used by many programs. Matching a library version to a program version would get really confusing, especially if a program uses multiple libraries.. (most do)
mritter0 wrote: With AmiUpdate there is no real reason not to be constantly updating and releasing the libraries and classes. If people see Hyperion actively developing, then it will motivate people to start/keep programming. I don't want to wait months for the new glyph.image with the new calendar image to come out.
Frequent updates are good. AmiUpdate has managed that quite well. :)
mritter0 wrote: For system libraries, bump revision if does not affect anything else (bug fixes only). Bump revision (bigger bump like 53.23 to 53.50) for additions that don't affect original usage. Bump version for additions that do affect other features.
As mentioned in my previous post, ALL changes to libraries are backwards compatible, meaning they do NOT affect original usage. Not doing so would be "very bad".
Increasing revision/version indicates bug fixes and/or newer features, but at no point should "original usage" be changed. If it did, then programs expecting the old way would suddenly be broken, and would only work if you booted to an old workbench. You can't keep an old fizzbot.library and a newer fizzbot.library both in libs:, because they have the same filename.
mritter0 wrote: If the programmers report that the libs/classes are too old, and specify, "You need listbrowser.gadget V53.99", with good alerts to the user, they can fire up AmiUpdate and get what they need. Not go to OS4Depot or have to Google it. AmiUpdate must be current.
I have standard code in all my programs for opening libraries and interfaces. If anything is not found, or does not have sufficient version, the user is notified with all the details.
But whether a library is available by AmiUpdate is really up to the library owner/maintainer.
chris
Posts: 552
Joined: Sat Jun 18, 2011 11:05 am
Contact:

Re: OpenLibrary(Name,Ver,Rev)

Post by chris »

mritter0 wrote:For system libraries, bump revision if does not affect anything else (bug fixes only).
Yes.
Bump revision (bigger bump like 53.23 to 53.50) for additions that don't affect original usage.
No. Revisions should always increase by one, and "original usage" should never be affected anyway.
Bump version for additions that do affect other features.
That should be "bump version for new features" (new functions).

A new OS release should have all the version numbers bumped. However, as explained, with AmiUpdate you can't really do that.

Possible solutions: Programs either have to check revision numbers as well (new features might not mean new version number), feature enhancements should only be released as a full OS upgrade, or version numbers should be allowed to go "out of sync".
Post Reply