7:26 p.m.
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
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
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.
I went ahead and use the new scheme for the tag, because it is more
concise. So the tag is under 2.1.0.Final.
7:51 p.m.
On 26 Jan 2013, at 7:26 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
nice
+1 I prefer this scheme as well
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
7:57 p.m.
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:
8:02 p.m.
On 26 July 2013 18:51, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
+1 it's far better as it avoids mistakes leading to conflicting
versions on classpath
Agree with Hardy. I never needed the feature myself but I suspect it
would useful to have an indication to which draft it's supposed to
refer to. At the same time you might have fixes which apply on the
same draft so I think this version could be more practical:
2.1.0-draft1-v2
but making sure the "draft" part of the scheme respects alphabetical
ordering.. I don't remember all rules but products use such a scheme
with -redhat-v2 or v3 at the end to match a community release + some
level of patching. Seems to work well for them.
8:20 p.m.
I do not agree with needing to see this in the artifact name. I can see
putting it in the metadata (pom, manifest, etc) in addition to Jira.
'draft' does in deed fit into the chronology scheme defined by JBoss.
Except that 'draft' is not defined as a valid value.
Here is another thing to consider. The first one I did was Draft-6
iirc. Whatever, it was not Draft-1 is my point. So if I see
'hibernate-jpa-api:2.1.0.Draft6' I immediately wonder where are 1-5.
Same when you combine. So say I have Draft-6 but the next release I cut
has Drafts 7 and 8. So I presume there you'd suggest
'hibernate-jpa-api:2.1.0.Draft8' there right? What happened to Draft 7?
Anyway, Andy started a conversation with other "spec api" owners to try
and get a consensus. I think consistency would be better.
On 07/26/2013 01:02 PM, Sanne Grinovero wrote:
4228
days inactive
4228
days old
4 comments
3 participants
participants (3)
-
Hardy Ferentschik -
Sanne Grinovero -
Steve Ebersole