Openbravo Issue Tracking System - Openbravo ERP |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0010999 | Openbravo ERP | A. Platform | public | 2009-10-15 19:17 | 2009-10-20 10:40 |
|
| Reporter | vmromanos | |
| Assigned To | alostale | |
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | |
| Platform | | OS | 20 | OS Version | Debian 5.0 |
| Product Version | pi | |
| Target Version | 2.50MP8 | Fixed in Version | | |
| Merge Request Status | |
| Review Assigned To | |
| OBNetwork customer | |
| Web browser | |
| Modules | Core |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0010999: Wrong module dependency version autoselected through the Module Management |
| Description | Imagine this case:
- Module B depends on module A (B--->A)
When defining this dependency in module B (Application Dictionary || Module || Module >> Dependency), the "first version" field for module A is 0.5.0. However the last version of A available at the central repository is 1.0.0, because new versions of A has been released.
If you try to install B through the Central Repository, it automatically marks to install A but, instead of using the last available version of A (1.0.0), it uses the version defined into the "first version" field (0.5.0).
|
| Steps To Reproduce | |
| Proposed Solution | Mark always to install the last version of the dependency available at the Central Repository |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | feature request | 0011033 | | new | iciordia | API checks on minor versions of modules |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2009-10-15 19:17 | vmromanos | New Issue | |
| 2009-10-15 19:17 | vmromanos | Assigned To | => rafaroda |
| 2009-10-16 13:59 | psarobe | Assigned To | rafaroda => alostale |
| 2009-10-16 13:59 | psarobe | Priority | normal => urgent |
| 2009-10-16 13:59 | psarobe | Status | new => scheduled |
| 2009-10-16 13:59 | psarobe | Target Version | => 2.50MP8 |
| 2009-10-16 16:32 | alostale | Status | scheduled => closed |
| 2009-10-16 16:32 | alostale | Note Added: 0021120 | |
| 2009-10-16 16:32 | alostale | Resolution | open => no change required |
| 2009-10-16 17:34 | vmromanos | Status | closed => new |
| 2009-10-16 17:34 | vmromanos | Resolution | no change required => open |
| 2009-10-16 17:34 | vmromanos | Note Added: 0021124 | |
| 2009-10-16 17:49 | alostale | Status | new => closed |
| 2009-10-16 17:49 | alostale | Note Added: 0021126 | |
| 2009-10-16 17:49 | alostale | Resolution | open => no change required |
| 2009-10-16 18:36 | iciordia | Note Added: 0021131 | |
| 2009-10-16 19:52 | vmromanos | Note Added: 0021136 | |
| 2009-10-17 00:01 | anonymous | sf_bug_id | 0 => 2880782 |
| 2009-10-19 11:50 | vmromanos | Relationship added | related to 0011033 |
| 2009-10-20 10:40 | iciordia | Note Added: 0021201 | |
|
Notes |
|
|
|
This is the correct behavior.
It tries to install the maximum available version in repository within the same major version, but it does not try to install a new major version since it could be not compatible with module B. |
|
|
|
|
I'm not agree with this behaviour.
The dependencies have a "last version" field, which should be taken into account. If last version is empty, then the last version available at the central repository should be used, independently of the major version of the module.
When you're working with a lot of modules it's a waste of time to release a new major version of all the dependent modules whenever you're releasing a new major version of the module. Moreover, if the module is included into one or more packs, then the mess is almost impossible to manage.
It would be easier for the user/developer to use the last version field and, if empty, always use the last version at the Central Repository |
|
|
|
|
This is done in this way because you cannot warranty the module will be compatible with a new major version since it can include changes in the API.
For example let's suppose your module dependency starts on core 2.50.0, it is warrantied that all 2.50.x release will keep API stable but it is not warrantied that 2.51.x API is still compatible. Thus it is very possible the module that was compatible with 2.50.x releases is not compatible anymore with the 2.51.x ones. |
|
|
|
|
Victor,
let me use "reduction to the absurd" for your proposal:
-You create module A v1.0.0
-I create module B v1.0.0 depending on your module A v1.0.0
-You publish a new version of A v2.0.0 and decide to do some changes in the API of your module
-With your proposal, my module is not working any more. CR will update to latest version of your module and my module does not work :-(
To improve maintenance you need to follow a better policy when publishing your modules. If your new versions are not modifying the public API of previous versions usually you should not change the major version so it is still compatible. And if it does big changes in scope -although API stays stable- you should change major version to avoid big changes in instances using your module through updates
Additionally you should review if your split in modules makes sense: small modules are meant to increase reusability. Check if your internal module (A in the example above) makes sense by itself. If not you are just adding overhead without any benefit
Hope it is clear. We worked hard on this spec. to properly support dependencies
Ismael |
|
|
|
|
Ismael,
In your example you don't have control over your dependency, so in this case you should use the "last version" field when defining the dependency. In your case, to ensure your module is always going to work, the "initial version" of the dependency should be equal to the "last version".
But now imagine a case where you have also developed your dependency, so you know exactly what you are doing in this module, and you know you're not going to change the API. You can safely leave the final version empty to ensure your module is always using the last available version of the dependency.
Summary:
With the "trick" of the major version you're proposing you cannot ensure your module will work in the future. Your dependency can change the API in a minor version and you're not going to realize it, thus your module won't work anymore.
Your approach is to TRUST the developers are not going to break the API in a minor version (you don't check it in the code); however my approach is to let developers enforce the last version of the dependency (if necessary) or to use always the last available version at the CR. In this way you can always ensure (with CODE CHECKS) that your module will work in the future, independently of the changes in the minor version.
Just my two cents |
|
|
|
|
Victor,
thanks for reporting that feature request (API checks on minor versions of modules).
After implementing this feature modules will have guarantee that dependencies will not change their public API. Till then we will have to trust that module is properly versioned.
Topic definitely closed :-)
Ismael |
|