- messages
    it is quite difficult to know exactly what messages should be output to the console or not, and it often
    depends on the user profile: beginner, expert, build manager, simple user, ...
    
    Being able to define the messages output in a single and homogeneous way could be a good thing.
    
    To allow this, maybe a solution could be to output messages in the code only by using keys:
    LOGGER.debug("unhandled.revision", mrid.getRevision());
    
    The LOGGER would be a constant initialised with the class name.
    
    a profile wold consist in a message.properties file, associating each key (prefixed by the FQCN) to a 
    message for the given profile. A key with no mapping result in no message at all.
    
    it would be possible to disable all messages of a class or activate only a certain level per class 
    (as in log4j for instance) to customize a profile at runtime
    
    shifting is costly, about 400 calls to messages

- promote task to update an already published module with a new status
	this task would also automatically update compatiblity data (see below)
- tag task to add one or several tags to an already published module
	tag could be added in a simple properties file next to the module ivy file
	this properties would be updated by this task
	every time ivy parses an ivy file, it would try to locate corresponding tag file,
	and if any load tags in the module descriptor instance
- compatiblity data
	tags could be used for to indicate that a module has some compatibility level
	with another one: if module A 2.0 has been tested successfully with B 1.0 and thus obtain status milestone, 
	then a tag "compatible.with.A.2.0=milestone" is put on B 1.0
	then latest version matcher code could be updated to handle something like this:
	latest.compatible.milestone 
	to be able to get the latest version of a dependency with at least a tag like
	compatible.with.A.[any revision]=milestone
	
	since all tags should be inspected to know that, maybe using an xml file like this would be better:
	<compatible>
		<module org="orga" name="A">
			<revision name="2.0" status="milestone"/>
		</module>
	</compatible>
	This would be cleaner, but less simple, and less flexible than using a tags system, which could be used
	for other use cases.
	
	Another solution would be to put two tags on B 1.0: one with A revision, and one without. The tag without 
	the revision could be used for latest.compatible.*, meaning that the last compatiblity status only would 
	be used. For instance, A 2.0 is said to be release compatible with B 1.0. using latest.compatible.release 
	is thus resolved to B 1.0. But now A 2.1 is built, and a first test tell that it is (at least) milestone
	compatible with B 1.0. The compatibility status of B is thus decreased  to milestone, and 
	latest.compatible.release is not resolved anymore to B 1.0, but maybe B 0.9... at least until the release
	compatibility tests are done on A. Then if it is release compatible, the tag is put back to the good status, 
	and if it isn't compatible, the compatiblity status is left to milestone, which is ok.
	Consequently the main problem with this solution is the time before all the tests are run. So maybe a module 
	should be promoted (and thus compatiblity status updated) only when all tests are done, or when an incompatible
	level is reached. Note that this solution is only acceptable in case of automatic tests. When the promotion is
	done by a QA team several days or even weeks after the previous status, maybe we can't wait for these tests
	to be done...
	Another solution would be to promote the module at eeach step, but only update the tag if the compatibility level
	is better than the previous one. Another task woudl then allow to indicate an incompatibility, if some level of 
	tests then fails.
	
	
	switching between latest compatible and latest version could also be done without any modification in ivy file:
	use latest.* dependency revision, and configure your resolve task to use compatible only versions.
	
	this way testing absolute latest version for a continuous integration server would be easy, and if the latest 
	version fails, latest compatible could be used easily, to test the module in a relative isolation of dependency 
	changes. In this case the continuous integration server should notify of the first failure before notifying of 
	the success of the compatible build: integration of latest modules has failed, but not the module itself.
	It would thus allow to have more often a latest successful build, even in case of api breaks.