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 <st...@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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
