Yes, version ranges work, but simply omitting the version won't do it. You could have [2.4,2.5) to pick up 2.4, 2.4-1, 2.4-2, etc. though.
Cheers, Brett On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Oh, I thought one of the big features of m2 was support for version > ranges. > > BTW I find the name servlet-2.4-1.0 confusing myself. > > -dain > > On Oct 31, 2005, at 12:10 PM, Brett Porter wrote: > > > Actually, I meant a version of 2.4-1, 2.4-2. > > > > I think there is advantages and disadvantages to each, so I'll let you > > all decide what's best to work with. I just wanted to point out that > > omitting the version won't work so it'll need to be specified, and > > personally I'd find that a bit confusing presented with: > > > > servlet-2.4-1.0. > > > > - Brett > > > > On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > > > >> Just to clarify you mean we should have this: > >> > >> <groupId>org.apache.geronimo.specs</groupId> > >> <artifactId>servlet-2.4</artifactId> > >> <name>Geronimo :: Servlet API</name> > >> <version>1</version> > >> > >> So the version number is a single non-dotted increasing integer? > >> > >> BTW for most APIs we will be able to simply release a certified > >> version and never update, but for some APIs, like JavaMail, are > >> mostly implementation code, we will have to to patch releases. Also > >> if we get into the habit of adding JavaDoc documentation over time, > >> we will have to do periodic release to get the line numbers in the > >> debug symbols to match-up. > >> > >> -dain > >> > >> On Oct 30, 2005, at 9:29 PM, Brett Porter wrote: > >> > >> > >>> I think this versioning has potential to be confusing, and the > >>> omission of <version/> below doesn't actually do that - though it is > >>> probably possible with a version of (,) that includes everything. > >>> > >>> Personally, I'd prefer to have: > >>> servlet-api-2.4 > >>> servlet-api-2.4-1 > >>> servlet-api-2.4-2 > >>> or similar. > >>> > >>> (Technically, the last "build number" is used for rebuilding the > >>> same > >>> source code, not patching, but I think the alternative of 2.4.x > >>> creates some more confusion and the above will work as intended). > >>> Ideally, once 2.4 is compliant you don't need to release it again > >>> anyway :) > >>> > >>> Perhaps when we have proper spec-dependency handling in Maven it > >>> might > >>> be less confusing to use the geronimo-spec version number instead of > >>> the spec number. > >>> > >>> My 2cents... > >>> > >>> - Brett > >>> > >>> > >>> On 10/30/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> I know this has been talked about before on this list, but I'd like > >>>> to get the proposal in one place. With the help of Alan and Jason, > >>>> this is what I got: > >>>> > >>>> Normally we just have this directory structure: > >>>> > >>>> specs/trunk/servlet-2.2/src/ > >>>> specs/trunk/servlet-2.4/src/ > >>>> specs/trunk/jsp-2.4/src/ > >>>> When we are happy with the specs we make a tag: > >>>> > >>>> specs/tags/1.0/servlet-2.2/src/ > >>>> specs/tags/1.0/servlet-2.4/src/ > >>>> specs/tags/1.0/javamail-2.2-r2/src/ > >>>> specs/tags/1.1/servlet-2.2/src/ > >>>> specs/tags/1.1/servlet-2.4/src/ > >>>> specs/tags/1.1/javamail-2.2-r2/src/ > >>>> The pom for the specs would be like this: > >>>> > >>>> <groupId>org.apache.geronimo.specs</groupId> > >>>> <artifactId>servlet-2.4</artifactId> > >>>> <name>Geronimo :: Servlet API</name> > >>>> <version>1.0</version> > >>>> With maven 2 version ranges a user can just have the following and > >>>> maven will pick the most resent release of our spec automatically: > >>>> > >>>> <dependency> > >>>> <groupId>org.apache.geronimo.specs</groupId> > >>>> <artifactId>servlet-2.4</artifactId> > >>>> <dependency> > >>>> > >>>> The current directory structure in https://svn.apache.org/repos/ > >>>> asf/ > >>>> geronimo/specs is very close to this. The only big change will > >>>> be to > >>>> add the version number of the specification to the directory name. > >>>> > >>>> What do yo think? > >>>> > >>>> -dain > >>>> > >>>> > >>> > >>> > >> > >> > > > >
