One option is a special qualifier. 2.2.1.Final (our bugfix) versus 2.2.1.Maintence (spec maintenance). Could still lead to "bad sorting", but does avoid collisions.
Also note that since 1.0 we have never needed a bugfix release. For what its worth... On Tue 27 Aug 2013 11:24:52 AM CDT, Gunnar Morling wrote: > I see. > > The reason I'm asking is that there theoretically could be a collision > between the version of such a maintenance release of the spec and a > previous bug fix release of our spec API JAR which e.g. would then > both have the version "2.2.1". > > Not sure whether one should be prepared for such a case or whether > it's actually no issue in practice. > > > 2013/8/27 Emmanuel Bernard <emman...@hibernate.org > <mailto:emman...@hibernate.org>> > > Technically the spec could go in what is called maintenance mode. In > which case the spec lead could use micro or some prefix like M1. > But we don't know if that will happen for JPA nor which one will be > chosen. > > Emmanuel > > On Tue 2013-08-27 10:55, Steve Ebersole wrote: > > I don't ever foresee that happening. I don't know that it is > > "guaranteed" anywhere though. > > > > On 08/27/2013 10:29 AM, Gunnar Morling wrote: > > > Sounds reasonable to me. > > > > > > One question only: It is guaranteed that the JPA spec itself never > > > will do a micro update, right? I.e. the spec would never be > updated > > > from say 2.2 to 2.2.1 (but to 2.3 in this case)? > > > > > > > > > 2013/8/27 Steve Ebersole <st...@hibernate.org > <mailto:st...@hibernate.org> > > > <mailto:st...@hibernate.org <mailto:st...@hibernate.org>>> > > > > > > I am contemplating duplicating[1] our existing JPA API > jars to use a > > > better GAV naming scheme, specifically the GAV naming > scheme we > > > plan on > > > adopting for any new JPA specs. We have used completely > different > > > naming scheme for 1.0 then we did for 2.0 and 2.1. And > even for > > > 2.0 and > > > 2.1 we used the JPA version in the artifactId rather than > the version > > > portion of GAV. > > > > > > The new scheme being proposed would be to use the groupId > we have been > > > using for 2.0/2.1 ("org.hibernate.javax.persistence"). We > would > > > use the > > > artifactId we have been using for 2.0/2.1, but without the > 2.0/2.1 > > > portion. Currently, for example, we have > "hibernate-jpa-2.1-api" > > > as the > > > artifactId; this would become just "hibernate-jpa-api". > We'd then > > > move > > > the JPA version as *part of* the GAV version. Essentially > the GAV > > > version would be broken into buckets with JPA version > taking up the > > > first 2 positions, a "bugfix" position, and then a > qualifier. Given > > > 1.0, 2.0 and 2.1 that would give us: > > > 1) > org.hibernate.javax.persistence:hibernate-jpa-api:1.0.0.Final.jar > > > 2) > org.hibernate.javax.persistence:hibernate-jpa-api:2.0.0.Final.jar > > > 3) > org.hibernate.javax.persistence:hibernate-jpa-api:2.1.0.Final.jar > > > > > > I would only duplicate the last of each of 1.0, 2.0 and > 2.1 into > > > the new > > > naming. > > > > > > Moving forward, the only thing that "changes" would be > qualifiers > > > if/as > > > we start working on new spec versions and possibly "bugfix" > > > portion (the > > > last '0') if we encounter problems in the jpa api jars > after the fact > > > (normal bugfix semantics). We are discussing > standardizing on this > > > across the JBoss community and specifically discussing how to > > > handle the > > > qualifiers for ongoing work. One option would be a new > qualifier > > > "Draft". It fits reasonably well in the existing (OSGi > defined) alpha > > > sorting of qualifiers aside from the Draft->Final jump > (what about > > > "Proposed Final Drafts"?). Personally I do not like the > direct tie to > > > specific spec Drafts; personally I know sometimes I > publish spec jars > > > that do not cleanly map to a Draft. I personally prefer using > > > Beta for > > > Drafts, CR for Proposed Final Drafts and Final for, well, > Final > > > Drafts. We'll have to see how that works itself out though. > > > > > > Anyway, any issues/concerns with duplicating these historical > > > artifacts? > > > > > > [1] I am thinking of duplicating rather than "relocating" > since I > > > am not > > > sure how well tools handle relocated artifacts in general. > In fact I > > > think tools (Maven itself included) simply fail to resolve the > > > relocated > > > artifact. > > > > > > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > <mailto:hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
