Just re-reading that I realised it could be a bit confusing as 2.4-1 and 2.4-1.0 look very similar.
The difference is that the first would be: <artifactId>servlet</artifactId> <version>2.4-1</version> as opposed to <artifactId>servlet-2.4</artifactId> <version>1.0</version> I think this is an interesting thing to discuss and perhaps feed back into the Maven default versioning rules to accommodate it in general if there is something better that we can come up with. - Brett On 11/1/05, Brett Porter <[EMAIL PROTECTED]> 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 > > >> > > > > > > > >
