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>> > > 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> > 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
