12 Replies Latest reply on Mar 14, 2008 11:17 AM by pgier

    Notion of 'compatible-version'?

    heiko.braun

      Does maven support the notion of 'compatible-version'?

        • 1. Re: Notion of 'compatible-version'?
          heiko.braun

          ALR wrote:



          Most I've seen from this is a wishlist/informal roadmap of sorts:

          http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

          Anyone know about the status of this?



          • 2. Re: Notion of 'compatible-version'?
            starksm64

            The http://maven.apache.org/release-notes.html show a number of issues related to version ranges as being fixed. The question is, what happens when you use them?

             <dependency>
             <groupid>org.jboss.x</groupid>
             <artifactid>x-api</artifactid>
             <!-- Compatible with all 3.3.* versions -->
             <version>[3.3.0,3.4.0)</version>
             </dependency>
            



            • 3. Re: Notion of 'compatible-version'?
              jason.greene

               

              "scott.stark@jboss.org" wrote:
              The http://maven.apache.org/release-notes.html show a number of issues related to version ranges as being fixed. The question is, what happens when you use them?


              You pray it works. We already know that our version strings are not interpreted correctly.

              • 4. Re: Notion of 'compatible-version'?
                wolfc

                Until we know how Maven handles ranges during its release cycle we should not be using that.

                Suppose the following:
                AS 5.0 depends on EJB3 [1.0,2.0)
                Current EJB3 release is 1.0.

                Now I release EJB3 1.1.

                How reproducable is the AS 5.0 build?

                It should also be doing a release cycle itself (which can be as simple as a nightly build) to perform an acceptance test on EJB3 1.1.

                • 5. Re: Notion of 'compatible-version'?
                  heiko.braun

                  Acceptance test is one thing, but having to release every dependency because of minor version upgrade (which IMO is supposed to be compatible) is not a way to go either.

                  If you don't favor ranges you could be explicit with compatible versions instead.

                  • 6. Re: Notion of 'compatible-version'?
                    heiko.braun

                     


                    We already know that our version strings are not interpreted correctly.


                    What are the problems you did encounter?

                    • 7. Re: Notion of 'compatible-version'?
                      starksm64

                       

                      "wolfc" wrote:
                      Until we know how Maven handles ranges during its release cycle we should not be using that.

                      Suppose the following:
                      AS 5.0 depends on EJB3 [1.0,2.0)
                      Current EJB3 release is 1.0.

                      Now I release EJB3 1.1.

                      How reproducable is the AS 5.0 build?


                      The mvn release plugin should be recording the versions used, and that version info committed as part of the tag. The release build should effectively be locked to single versions.

                      How reproducible the trunk/branch build is remains.

                      • 8. Re: Notion of 'compatible-version'?
                        starksm64

                        Clearly the version resolution should be pluggable. The current behavior and issue to make this pluggable is:
                        http://jira.codehaus.org/browse/MNG-612

                        • 9. Re: Notion of 'compatible-version'?
                          wolfc

                           

                          "heiko.braun@jboss.com" wrote:
                          Acceptance test is one thing, but having to release every dependency because of minor version upgrade (which IMO is supposed to be compatible) is not a way to go either.

                          If you don't favor ranges you could be explicit with compatible versions instead.

                          Suppose the following:
                          AS 5.0 depends on EJB3 [1.0,2.0)
                          EJB3 1.0 depends on MetaData [1.0,2.0)
                          Current MetaData is 1.0.

                          Now I release MetaData 1.1 for AS trunk.
                          scott.startk@jboss.org wrote:
                          The mvn release plugin should be recording the versions used, and that version info committed as part of the tag. The release build should effectively be locked to single versions.

                          In the repo it should have been noted as:
                          AS 5.0-1 -> EJB3 1.0-1
                          EJB3 1.0-1 -> MetaData 1.0-1

                          To update the repo an EJB3 1.0 release must be done:
                          EJB3 1.0-2 -> MetaData 1.1-1.

                          At which point AS 5.0-1 -> EJB3 1.0-1 -> MetaData 1.0-1 is reproducable.

                          Followed by AS 5.0 release:
                          AS 5.0-2 -> EJB3 1.0-2.

                          Ivy works that way and so should Maven.
                          But I don't see how it works with Maven and transitive dependencies.

                          • 10. Re: Notion of 'compatible-version'?
                            pgier

                             

                            "wolfc" wrote:

                            Ivy works that way and so should Maven.
                            But I don't see how it works with Maven and transitive dependencies.


                            There is a feature of the release plugin to generate release poms http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html
                            When I tried using it a while back it wasn't working very well, but there have been a few releases since then so maybe it's improved.

                            This is also something that release engineering is working on. Their approach is to save the whole environment that was used during the build. This includes everything that was downloaded to the local repository, so only these things would be available when reproducing the build.


                            • 11. Re: Notion of 'compatible-version'?
                              starksm64

                              Can we get to a version of maven that supports the pluggable version resolution policy and set it to what we want?

                              • 12. Re: Notion of 'compatible-version'?
                                pgier

                                The issue that you mentioned earlier (http://jira.codehaus.org/browse/MNG-612) is assigned for 2.1 which is still a long way down the road. Although the comments say it should be 2.0.x. Also, even if it gets resolved, I'm not sure it would help us if we are not using the standard maven version numbers.

                                It would be nice to have a real "pluggable" version parser and resolution where we could write our own version rules and list it as a build extension in the pom or something like that. I can bring this up on the maven dev list, but my prospects for having time to actually work on this are not too good for the near future.