Branching for a 2.0-M6 is a short lived process and basically what
we've done over the past few months. I'll branch, fix up / clean up
and andy patches there will be small and easily managed in two
branches. This isn't intended to be a long lived maintenance
problem. We've been there and done that and don't plan on returning.
On Jun 1, 2007, at 11:29 PM, Jarek Gawor wrote:
One thing I would be in favor of is branching only when we are
actually ready for 2.0 final. Otherwise, we will have two trees to
commit our patches to and keep in synch. And that is always
problematic.
Jarek
On 6/1/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
I like Kevan's suggestion. We ship the assemblies we normally build.
On Jun 1, 2007, at 8:28 PM, Gianny Damour wrote:
> On 01/06/2007, at 3:56 AM, David Jencks wrote:
>
>>
>> On May 31, 2007, at 9:53 AM, Matt Hogstrom wrote:
>>
>>> There has been lots of work going on to get Geronimo 2.0
>>> certified and it seems like the light at the end of the tunnel is
>>> not an oncoming train but the other side :) With that we're also
>>> at the point of cutting a milestone since we're at the end of
>>> May. Given that all possible assemblies won't be fully tested
>>> what do folks think about the name of the release and what will
>>> it contain? Also, when is a branch appropriate?
>>>
>>> I was thinking geronimo-tomcat-jee5-2.0-M6. This would include
>>> Tomcat, CXF and OpenJPA as the components. The M6 indicates a
>>> work in progress but allows us to claim a specific release as
>>> certified and allows us to continue knocking off the corners for
>>> performance, footprint, etc.
>>
>> Why not also a jetty assembly? Unless there are really
>> significant problems I'd be in favor of waiting a couple days and
>> getting both platforms out at the same time.
>
> I am also in favor of a simultaneous release of Jetty and Tomcat
> assemblies.
>
> Thanks,
> Gianny
>
>>
>>>
>>> It would also seem about right to branch into branches/2.0 at
>>> this time as we finish the other work.
>>>
>>> What do others think?
>>>
>>
>> I have a significant security refactoring I've been working on
>> that I would like to get into the next 2.0 official whatever
>> (milestone, snapshot, release...) since it is not backwards
>> compatible. It affects how default subjects and run-as subjects
>> are constructed and will finish the JACC plugability work. I'll
>> try to get something out today describing how it works in more
>> detail.
>>
>> thanks
>> david jencks
>>
>>> Matt
>>
>
>
