11:30 a.m.
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 <emmanuel(a)hibernate.org
<mailto:emmanuel@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 <steve(a)hibernate.org
<mailto:steve@hibernate.org>
> > <mailto:steve@hibernate.org <mailto:steve@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(a)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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev