Good point about the TCK but I think we should handle that slightly differently then what you are suggesting.
Why not test the TCK agains the trunk core with the branch commons? If it passes you release commons. At that point you are not likely to need to fix anything on the upcoming core branch that would require a commons change. If you do, then just release commons again. I like to get away from using release candidates. We will be able to release faster if we just specify a project and svn revision that we are voting on. Sean On 2/17/06, Bruno Aranda <[EMAIL PROTECTED]> wrote: > And what about the TCK when releasing core, it should go before any > release (commons and core), right? If it fails due to something in > commons we may have to fix commons. Instead of put commons directly to > final I would change it to release candidate and only after TCK is > passed put it final. > > Regards, > > Bruno > > On 2/17/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > > And at some future point, we'll probably also incorporate a > > > "repackaging" step into one of these (I'd suggest core, probably) to > > > give the two commons versions different namespaces. > > > > That's what I'm attracted at more and more, too. ;-) > > > > Manfred > > >
