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, Gun
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 ca
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 hap
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 b
Well thats the beauty of duplicating (in theory). Nothing really to
fight. Now if we were doing relocation, yes I'd agree with you :)
On 08/27/2013 10:28 AM, Emmanuel Bernard wrote:
> On Tue 2013-08-27 10:22, Steve Ebersole wrote:
>> On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard 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
> I am contemplating duplicating[1] our existing JPA API jar
On Tue 2013-08-27 10:22, Steve Ebersole wrote:
> On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard wrote:
> >+1 to have a suffix not related tot he draft. Like you I have pushed
> >spec jars that did not reflect eh state of a draft necessarily.
> >
> >BTW, why retrofit that scheme? Why not just
On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard wrote:
> +1 to have a suffix not related tot he draft. Like you I have pushed
> spec jars that did not reflect eh state of a draft necessarily.
>
> BTW, why retrofit that scheme? Why not just apply it for 2.1?
Well applying it for 2.1 is in fact
+1 to have a suffix not related tot he draft. Like you I have pushed
spec jars that did not reflect eh state of a draft necessarily.
BTW, why retrofit that scheme? Why not just apply it for 2.1?
Emmanuel
On Tue 2013-08-27 9:57, Steve Ebersole wrote:
> I am contemplating duplicating[1] our exist
