Hello, 2007/11/27, [EMAIL PROTECTED] <[EMAIL PROTECTED] >: > > It sounds odd to have that many release version per day.
Yes indeed. Well, not per day, but per week. Nevertheless, it is odd. Version range > notation would be perfect for what you need.. The first thing we will try is to use ranges like [2.1,) If I understand ranges correctly, then whenever we release this fast moving artifact (the version moves up) all the clients will pick the latest release version. Someone mentioned 2.0.7 has problems with ranges? Is there a JIRA issue? Cheers, Borut i.e., > > [2.1, ) > > Having said that I found a number of problems with using version range and > I am stuck with 2.0.6 because 2.0.7 gives me NPE when it tries to resolve > conflict between version ranges. > > Cheers, > rOnn c. > > > > > > "Borut Bolčina" <[EMAIL PROTECTED]> > 11/26/2007 06:31 PM > Please respond to > "Maven Users List" < [email protected]> > > > To > Maven <[email protected]> > cc > > Subject > Version moving up fast > > > > > > > Hello maven users, > > if one of our in-house jars (lets call it A.jar) is progressing fast in > terms of artifact version numbers (several times per week: 2.1 -> 2.2 > -> 2.3-> ... - > > 2.678 -> 2.679 -> ...), what is the best way for other artifacts which > depend on this "fast one" to always use the last one? All the artifacts > which depend on the A, would have to have their poms modified to > 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the > trunk. This is error prone. I haven't looked into the release plugin yet, > but I don't think it addresses this issue. > > One solution might be to name the A's version to something like > 999-SNAPSHOT > and then all the other jars would have their dependencies to this version. > This smells like a dead fish in the sewer to me. > > What do you say? > > > ###################################################################### > DISCLAIMER: > This email and any attachment may contain confidential information. > If you are not the intended recipient you are not authorized to copy > or disclose all or any part of it without the prior written consent > of Toyota. > > Opinions expressed in this email and any attachments are those of the > sender and not necessarily the opinions of Toyota. > Please scan this email and any attachment(s) for viruses. > Toyota does not accept any responsibility for problems caused by > viruses, whether it is Toyota's fault or not. > ###################################################################### >
