Manfred,
See below.

Manfred Geiler wrote:
inline >>>

On 2/6/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
Manfred Geiler wrote:
> On 2/6/07, Paul Spencer <[EMAIL PROTECTED]> wrote:
<snip>

>>
>> IMHO we should not add a SNAPSHOT dependency until their their is a
>> change from the released version of the dependency. This will minimize
>> the number of projects to released.  Thus at the end of the release
>> process, only the following SNAPSHOT dependencies should exist:
>
> See above. There are no officially available non-SNAPSHOT releases for
> "maven-project" or "shared" or "core" yet.
>
>
>> In addition the snapshot dependency should not be add until AFTER the
>> release is cut.
>
> Same problem and additional danger here:
> Imagine a developer changes something and forgets to increase the
> version number of the artifact from "x.y.z" to "x.y.z-SNAPSHOT". If he
> does a mvn install (or a mvn deploy!!!) he will have a total version
> chaos in his local repo: He will have local artifacts with version
> x.y.z that differ to the official released artifacts with the same
> version number!
>
> See description of the maven release plugin [1] for best practice and
> to learn how others are doing.
>

The version of the artifact should be a SNAPSHOT for the above reason.
I am referring to how the artifact is used.  As an example, Tomahawk
v1.1.5 will be dependent on maven-project v2.0.5. My comment was related
to Tomahawk v1.1.6-SNAPSHOT.  Should it be dependent on maven-project
v2.0.5 or v2.0.6-SNAPSHOT?

My feeling is that it should depend on maven-project v2.0.6-SNAPSHOT
because it seems safer in case someone checks in something into the
maven-project that is incompatible to tomahawk. This will be detected
then during continuum nightly build at the latest.

Well, and as mentioned before, there does not exist an official
maven-project v2.0.5 yet.

Do you mean, we should freeze tomahawks dependencies to maven-project
(and shared) until some new feature or fix is added to these artifacts
that is needed in tomahawk?  Hmm. My feeling is that it makes more
problems than it solves. I think the best thing is to keep all MyFaces
"intra dependencies" on the trunk(s) at the latest ie. every
subproject uses the latest snapshot version of each other. Upon
releasing there is still a chance to turn back the dependency to an
artifact that has not changed since the last release.

That means: When we release a new tomahawk version in a few weeks and
the dependency to maven-project v2.0.6-SNAPSHOT there will be two
possibilities:
- there is NO diff between maven-project v2.0.5 and v2.0.6-SNAPSHOT
--> voila, we can release tomahawk with a dependency to maven-project
v2.0.5
- there is A diff between maven-project v2.0.5 and v2.0.6-SNAPSHOT -->
we must publish an official maven-project v2.0.6 release first and
then release tomahawk with a dependency to maven-project v2.0.6

Thoughts?


Their is a balance here. If a dependent project is likely to change then by all means depend on the SNAPSHOT, otherwise depend on the released version.

Dependency on maven-project-2.0.6-SNAPSHOT:
  Pro:
  o Dependent project will not have to update their dependency after
    the first commit to maven-project.
  Con:
  o More work during the release process if their is not change to
    maven-project. I.e. the release manage has to either release
    maven-project 2.0.6 or update the dependent projects to use
    2.0.5
  o Maven 2.0.4 has some issues around retrieving snapshot that are
    dependencies of a snapshot.

If their is no difference between maven-project (or shared) between MyFaces and Tomahawk, then the same version of maven-project should be used. From a developers stand point the minimized issues like "what version of this artifact should I be using" and "what has changed". I am not advocating a "freeze" since a freeze may prevent, or unnecessarily complicate, a fix to Tomahawk.

In short my preferences is to keep the dependency on snapshots to a minimum, but I understand their are occasion when they are necessary.


--Manfred


Paul Spencer

Reply via email to