0010999: Wrong module dependency version autoselected through the Module Management

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