Difference between revisions of "ProposalLibraryDependencies"
| Line 1: | Line 1: | ||
| + | [[Category:EiffelStudio]] | ||
| + | [[Category:Configuration]] | ||
= Problem = | = Problem = | ||
Almost every Eiffel library has dependencies on other Eiffel libraries, at the moment those dependencies are specified by using a hard coded file location or expecting the library to be under $ISE_LIBRARY. This solution is not optimal for several reasons: It does not allow flexible installation of additional libraries if the user does not have write permissions in the $ISE_LIBRARY directory, it does not allow to have different, incompatible versions of a library installed at the same time. | Almost every Eiffel library has dependencies on other Eiffel libraries, at the moment those dependencies are specified by using a hard coded file location or expecting the library to be under $ISE_LIBRARY. This solution is not optimal for several reasons: It does not allow flexible installation of additional libraries if the user does not have write permissions in the $ISE_LIBRARY directory, it does not allow to have different, incompatible versions of a library installed at the same time. | ||
| Line 11: | Line 13: | ||
== Implementation == | == Implementation == | ||
A repository would map the name, version numbers to actual configuration files. Initially this could be implemented by giving a list of directories to search for libraries, later a possibility to get libraries from an online repository could be added (similar to the Debian apt system). | A repository would map the name, version numbers to actual configuration files. Initially this could be implemented by giving a list of directories to search for libraries, later a possibility to get libraries from an online repository could be added (similar to the Debian apt system). | ||
| + | |||
| + | === Versioning === | ||
| + | As it should be possible for a library author to differentiate between bugfixes that don't change the library interface and interface changes, the version numbers should be used similar to the way it is done with shared libraries in the Unix world. The version number consists of four components: major.minor.release.build as long as major.minor version is equal, the library is expected to have the same interface and a newer version would replace an older version. If major.minor version would change this would lead to an additional available version. | ||
| + | |||
| + | == Example == | ||
| + | '''library com.eiffel.base version 5.7.1.1''' | ||
| + | |||
| + | '''library com.eiffel.wel version 2.1.2.3''' | ||
| + | *com.eiffel.base min_version=5.7 max_version=5.7 | ||
| + | |||
| + | '''library com.eiffel.vision2 version 2.5.3.1''' | ||
| + | *com.eiffel.base min_version=6.0 max_version=6.0 | ||
| + | *com.eiffel.wel min_version=2.5 max_version=2.5 | ||
| + | |||
| + | Installing com.eiffel.base version 5.7.2.1 would replace 5.7.1.1, installing 6.1.1.1 would just additionally install the new version. | ||
Latest revision as of 13:44, 13 November 2006
Contents
Problem
Almost every Eiffel library has dependencies on other Eiffel libraries, at the moment those dependencies are specified by using a hard coded file location or expecting the library to be under $ISE_LIBRARY. This solution is not optimal for several reasons: It does not allow flexible installation of additional libraries if the user does not have write permissions in the $ISE_LIBRARY directory, it does not allow to have different, incompatible versions of a library installed at the same time.
Proposal
Library creation
A library gets a unique name and a version number.
Library usage
Instead of specifying the configuration file of the library, the name of the library and (optionally) a min/max version are specified.
Implementation
A repository would map the name, version numbers to actual configuration files. Initially this could be implemented by giving a list of directories to search for libraries, later a possibility to get libraries from an online repository could be added (similar to the Debian apt system).
Versioning
As it should be possible for a library author to differentiate between bugfixes that don't change the library interface and interface changes, the version numbers should be used similar to the way it is done with shared libraries in the Unix world. The version number consists of four components: major.minor.release.build as long as major.minor version is equal, the library is expected to have the same interface and a newer version would replace an older version. If major.minor version would change this would lead to an additional available version.
Example
library com.eiffel.base version 5.7.1.1
library com.eiffel.wel version 2.1.2.3
- com.eiffel.base min_version=5.7 max_version=5.7
library com.eiffel.vision2 version 2.5.3.1
- com.eiffel.base min_version=6.0 max_version=6.0
- com.eiffel.wel min_version=2.5 max_version=2.5
Installing com.eiffel.base version 5.7.2.1 would replace 5.7.1.1, installing 6.1.1.1 would just additionally install the new version.
