Well to be totally honest I don't see what we gain from it but if you
want to try just do!
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2013/11/8 David Blevins :
> Not ideal
Not ideal, but at this point I'm willing to try anything at least once.
I'm more curious to see if it works than anything.
-David
On Nov 7, 2013, at 11:09 PM, Romain Manni-Bucau wrote:
> Mens well have 2 trunks with same code...im not in love
> Le 8 nov. 2013 08:02, "David Blevins" a écrit :
Mens well have 2 trunks with same code...im not in love
Le 8 nov. 2013 08:02, "David Blevins" a écrit :
> Heads up, making the branch for 1.6.0.
>
> As sort of a crazy idea, I thought it might be interesting to branch for
> 1.6.1 now as well. Our intention would be to get this out *immediately*
Heads up, making the branch for 1.6.0.
As sort of a crazy idea, I thought it might be interesting to branch for 1.6.1
now as well. Our intention would be to get this out *immediately* after 1.6.0
and I think it might help confidence that this will actually occur if we
effectively start that re
Cool, will revert it when I pull everything over. Looks fairly simple.
-David
On Nov 7, 2013, at 10:45 PM, Romain Manni-Bucau wrote:
> He has mail, no time to work but enough to say us. At least youd need to
> rever openjpa 2335 and check openjpa and tck are still passing
> Le 8 nov. 2013 07:4
He has mail, no time to work but enough to say us. At least youd need to
rever openjpa 2335 and check openjpa and tck are still passing
Le 8 nov. 2013 07:43, "David Blevins" a écrit :
> Note, wait-and-talk-to-mark is essentially option C as Mark isn't back
> from JAX till next week.
>
> So far op
Note, wait-and-talk-to-mark is essentially option C as Mark isn't back from JAX
till next week.
So far option B seems the dominant choice. I'll get started with that and try
and get some binaries up for tire-kicking then go to bed.
-David
On Nov 7, 2013, at 9:58 PM, Romain Manni-Bucau wrote
Ping Mark to know what is the openjpa regression. If blocking wait openjpa
(or do the fix), if not B (or with the fix in our fork)...
I just dont want a blind release
Le 7 nov. 2013 22:38, "Alex The Rocker" a écrit :
> +1 for option B, and I like the idea of a 1.6.1 maintenance release with
> Op
+1 for option B, and I like the idea of a 1.6.1 maintenance release with
OpenJPA final in it, that's a perfect one if option B can be provided super
fast (this week at least as a release candidate)
Otherwise it'll amount to option C for us :(
Thanks
Alex
On Thu, Nov 7, 2013 at 10:32 PM, Jean-L
Need to check whereas the option A is possible.
I'm for B, but I would add the following: release 1.6.1 release maintenance
as soon as OpenJPA gets released. Release maintenance only, no new
features. Only big bugfixes and dep updates.
Latest option is not acceptable for me
To summarize:
A = 0
B
So we need to start getting builds for Alex, Tim, Judah and crew or they won't
be able to move forward with TomEE.
We just have the OpenJPA issue to deal with. We have two options:
A. Release with OpenJPA 2.2.2
B. Release with OpenJPA 2.3.0 "pre" build of our creation -- we've done this
with
11 matches
Mail list logo
