[Gambas-bugtracker] Bug #1746: Add ability to include Major Version number as part of the package name

[bugtracker at gambaswiki.org]

http://gambaswiki.org/bugtracker/edit?object=BUG.1746&from=L21haW4-

Brian G reported a new bug.

Summary
-------

Add ability to include Major Version number as part of the package name

Type             : Request
Priority         : Medium
Gambas version   : Master
Product          : Development Environment


Description
-----------

Add ability to include the major revision number as part of the shared library installation package name.

Currently each install package released deletes all the older versions of the library.

In Linux the major number denotes the interface level as a standard for shared libraries.

What I am talking about is allowing the major version number of the shared library to control the name of the package
to be changed such that their could be available to an application developer  multiple versions of the library.

This does not change the library name.

Nor would it at all change the dependency chain of your install package or older versions of the app being reinstalled
as both versions would be available to resolve dependencies during the install.

Both

company.bogolib.1.0.0
and
company.bogolib.2.0.0

Are available now, the original apps dependencies are unchanged and resolve correctly.

I don't believe you can link a libc:10 lib with a cc4 compiled and developed app and have it work correctly.
But developers don't usually like the lib name to change, when the environment is updated.

I does in fact allow you to control the version of interface your application uses.

If you need your old app to use the old version of a library
don't change the major version number for that apps version of the library during bug fixes and changes.

Update the minor version numbers of the library after the changes to it. That way you Stay compatible.

>From a shared library developers point of view:

This allows the release of publicly available libraries with interface specs that can be changed and the app builder/designer can decide to upgrade
or not to the new super duper version of the library for his new release without compromising the existing installed or reinstalled base.

>From Application Developers point of View :

When you release a updated version of your app that requires a lib with some not compatible changes to the interface
enhancing the performance/ability etc then it is time to bump the major number and release the
app with the bumped interface number.

This In fact allows your older version app to happily co-exist with the new one. And even be reinstalled.
And future change and bug fixes to the library without issues.

If in the future you would like your old App to use the new library for some reason then it is time to update it.
In this case you are in fact releasing a new version of the app.

So maybe its dependency chain should be updated.

Are All your shared libraries open source?

I am not trying to make anyone's life more difficult here. I am only trying to smooth the over all development cycle and app redevelopment
cycle.

I really believe that this would be a useful and well used tool during the development and release cycle.

I have made a merge request adding the ability for the Scripter to use only the major release number or Major Minor release number for shared libraries. 

Today I thought the IDE had to select a specific version of the library to link with. 
Maybe I don't understand well enough. Components don't care about the release information just the Gambas version
but shared libraries depend on the release information in the IDE.
maybe the IDE needs tweeked to allow filtering on major number only as well if it does not already do that.

Initially my thoughts turn towards script by default.


Thank You
Brian G


System information
------------------

Master