////
   Licensed to the Apache Software Foundation (ASF) under one
   or more contributor license agreements.  See the NOTICE file
   distributed with this work for additional information
   regarding copyright ownership.  The ASF licenses this file
   to you under the Apache License, Version 2.0 (the
   "License"); you may not use this file except in compliance
   with the License.  You may obtain a copy of the License at

     https://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing,
   software distributed under the License is distributed on an
   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
   KIND, either express or implied.  See the License for the
   specific language governing permissions and limitations
   under the License.
////

- 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 compatibility 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

- compatibility 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 compatibility 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 compatibility 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 compatibility 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 each step, but only update the tag if the compatibility level
is better than the previous one. Another task would 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.