Re: [hibernate-dev] JPA API jar
Well the problem comes up in versions like '1.0.0.Draft-7plus', which
was Draft-7 + some stuff we had just discussed in the EG. Or what
about cases where we are combining work from a few drafts? All in all,
its not great.
What I was thinking instead is to use Alpha/Beta/CR and in the Jira
notes for that release discuss what is covered. That is much easier to
convey in text (Beta4 includes updates in Draft 7 of the spec, plus
additional updates for schema generation discussed in the EG that will
make their way into Draft 8...) than it is in a concise version name
imo.
And yes I have discussed this Andy so that we can be consistent across
all spec api jars.
On Fri 26 Jul 2013 12:51:49 PM CDT, Hardy Ferentschik wrote:
On 26 Jan 2013, at 7:26 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
> I just released the "Final" JPA API jar. It is still using the old
> naming scheme in terms of repo artifacts; so this one is:
>
> groupId : org.hibernate.javax.persistence
> artifactId : hibernate-jpa-2.1-api
> version : 1.0.0.Final
nice
>
> I think moving forward we will move to a slightly different scheme. The
> group will stay the same, but:
>
> artifactId : hibernate-jpa-api
> version : {jpaVersion}.0.Final
+1 I prefer this scheme as well
> Also, rather than naming the non-final releases after the draft they
> come from (because often they span Drafts or partially include Drafts,
> etc) we'll just go to a straight Alpha/Beta/CR scheme.
how do you know how many releases there are of each type and when to switch?
Is that an arbitrary choice? Personally I had not problems with the Draft naming
scheme, but if you think this is better.
--Hardy