Comments/questions about the use of snapshot dependencies during the release process.
Should the versions of maven-project be set to 1.0.5 for all projects, not 1.0.6-SNAPSHOT? I have a similar same question for all dependent projects. 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: shared-core myfaces-impl tomahawk-impl any project dependent on the above In addition the snapshot dependency should not be add until AFTER the release is cut. Paul Spencer
Re: Comments/questions about the use of snapshot dependencies during the release process.
On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: Should the versions of maven-project be set to 1.0.5 for all projects, not 1.0.6-SNAPSHOT? That won't work because as long as the release process is not finished, the maven-project 1.0.5 only exists on the (inofficial) staging repo under http://people.apache.org/builds/myfaces/m2-staging-repository/ So, a developer build of the trunk would fail, because the staging repo is no standard repo and the artifact could not be found. So the correct intra-project dependency linking on the trunk is always *-SNAPSHOT. Leaving it at 1.0.5-SNAPSHOT is also no good idea, because new additions and changes on the trunk would go into the nightly snapshot builds, that would still be versioned 1.0.5-SNAPSHOT but differ more and more to the branched 1.0.5 version. I have a similar same question for all dependent projects. 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. --Manfred [1] http://maven.apache.org/plugins/maven-release-plugin/
Re: Comments/questions about the use of snapshot dependencies during the release process.
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? --Manfred [1] http://maven.apache.org/plugins/maven-release-plugin/ Paul Spencer
Re: Comments/questions about the use of snapshot dependencies during the release process.
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? --Manfred
Re: Comments/questions about the use of snapshot dependencies during the release process.
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
Re: Comments/questions about the use of snapshot dependencies during the release process.
inline-- On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: 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. Paul, I agree with most of your arguments. And you are right, there must be a tradeoff between the likelyhood of a subproject to change and dependent projects. But there is one more Pro for a dependency on maven-project-2.0.6-SNAPSHOT that just came to my mind and that might be the cause for my feeling that intra project dependencies should always be the latest snapshots: When people check out the current meta-project and do a complete build they expect to have a clean compile of every artifact and that there are no dependencies to old artifacts. That's one of the major pitfalls of maven: When you build an aggregated meta-project most people would expect it to act like a make all and compile and link together what they have on their disk. Now, if there are dependencies to project artifacts of an older version this might have dreadful sideeffects.
Re: Comments/questions about the use of snapshot dependencies during the release process.
On 2/6/07, Manfred Geiler [EMAIL PROTECTED] wrote: I'm almost finished with core 1.1.5 preparations and already have changed all dependencies to the next SNAPSHOT versions. Although there should be more discussions regarding this issue, I would like to go on like I have started. Please do not take this as an act of ignorance. All right? Just to clarify, I think that when Manfred says Please do not take this as an act of ignorance, he means that he's not ignoring your concerns. Manfred, it could easily be read in English as a rebuttal proclaiming that you're not ignorant about this process and to stop bothering you, but I'm sure this is not your intent :-)
Re: Comments/questions about the use of snapshot dependencies during the release process.
On 2/6/07, Mike Kienenberger [EMAIL PROTECTED] wrote: On 2/6/07, Manfred Geiler [EMAIL PROTECTED] wrote: I'm almost finished with core 1.1.5 preparations and already have changed all dependencies to the next SNAPSHOT versions. Although there should be more discussions regarding this issue, I would like to go on like I have started. Please do not take this as an act of ignorance. All right? Just to clarify, I think that when Manfred says Please do not take this as an act of ignorance, he means that he's not ignoring your concerns. Yes, that is exactly what I meant. Manfred, it could easily be read in English as a rebuttal proclaiming that you're not ignorant about this process and to stop bothering you, but I'm sure this is not your intent :-) Mike, thanks for watching and clarifying. --Manfred
Re: Comments/questions about the use of snapshot dependencies during the release process.
Manfred, First off, regardless of the outcome this discussion should not hold up the current release process. In fact, lets wait until it is done. Thank you for working on the release. Paul Spencer Manfred Geiler wrote: inline-- On 2/6/07, Paul Spencer [EMAIL PROTECTED] wrote: 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. Paul, I agree with most of your arguments. And you are right, there must be a tradeoff between the likelyhood of a subproject to change and dependent projects. But there is one more Pro for a dependency on maven-project-2.0.6-SNAPSHOT that just came to my mind and that might be the cause for my feeling that intra project dependencies should always be the latest snapshots: When people check out the current meta-project and do a complete build they expect to have a clean compile of every artifact and that there are no dependencies to old artifacts. That's one of the major pitfalls of maven: When you build an
