Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
ID
0010999
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[Openbravo ERP] A. Platformmajoralways2009-10-15 19:172009-10-20 10:40
ReportervmromanosView Statuspublic 
Assigned Toalostale 
PriorityurgentResolutionno change requiredFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version2.50MP8
OSLinux 32 bitDatabasePostgreSQLJava version1.6.0_12
OS VersionDebian 5.0Database version8.3.7Ant version1.7.0
Product VersionpiSCM revision 
Review Assigned To
Web browser
ModulesCore
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0010999: Wrong module dependency version autoselected through the Module Management

DescriptionImagine 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).
Proposed SolutionMark always to install the last version of the dependency available at the Central Repository
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to feature request 0011033 newiciordia API checks on minor versions of modules 

-  Notes
(0021120)
alostale (manager)
2009-10-16 16:32

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.
(0021124)
vmromanos (manager)
2009-10-16 17:34

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
(0021126)
alostale (manager)
2009-10-16 17:49

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.
(0021131)
iciordia (manager)
2009-10-16 18:36

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
(0021136)
vmromanos (manager)
2009-10-16 19:52

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
(0021201)
iciordia (manager)
2009-10-20 10:40

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

- 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


Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker