Hi Christian, All your JMS refactoring patches are in the 2.0.x branch and the test result looks good :)
Willem On Sat, Oct 4, 2008 at 8:30 AM, Willem Jiang <[EMAIL PROTECTED]> wrote: > Hi Christian, > > Most of your JMS patches were merged into the 2.0.x branch , and there are > not much differences between the CXF 2.0.x JMS module and CXF 2.1.x JMS > module. I think it is easy to merge your latest change into the CXF 2.0.x. > Don't worry , I will keep on an eye on it ;) > > Willem > > Christian Schneider wrote: > >> Hi Dan, >> >> I have got a question about the new releases. Should we include the >> changes in the JMS transport in one of them? >> Ron Gavlin asked to include the changes in the 2.0.x branch on the jira >> issue https://issues.apache.org/jira/browse/CXF-1832. >> I could imagine to include them into 2.1.3 but I would rather leave them >> out of 2.0.9. What do you think? Are there some general guidelines how to >> handle this? >> >> Is there already a time scale? I would like to include the upcoming new >> JMS configuration style in the release but this will take at least another >> one or two weeks. >> >> Greetings >> >> Christian >> >> >> Daniel Kulp schrieb: >> >>> We're rappidly approaching time to do the 2.0.9 and 2.1.3 releases. >>> It's been about 10 week since 2.0.9 and 7 weeks since 2.1.2. We have >>> 33 issues resolved for 2.0.9, and 38 for 2.1.3. Thus, we probably >>> should consider doing some releases shortly. >>> >>> HOWEVER, my hard drive crashed this week and part of recovering from >>> that, I kind of realized that someone else really should try doing a release >>> to make sure the knowledge is spread out a bit and isn't all bottled up in >>> my head. Thus, I'd like to ask for volunteers for doing the releases. >>> If no one jumps up, I'll be happy to do it, but it would definitely be good >>> to get someone else involved. >>> >>> Requirements: >>> 1) The release process is MUCH easier and more reliable on a Linux or OSX >>> box. Things like gpg and ssh/scp "just work". If someone want to try >>> Windows, I'm not sure how much I can help. 2) gpg installed and a gpg key >>> generated and available in the public key servers. Ideally, it would be >>> signed by other apache folks, but that's not a requirment. Anyone near >>> Boston, we could meet for lunch and sign keys if you want. >>> >>> 3) Time - before building the release, you need a few hours to review >>> release notes, notice/license files, rat reports, etc.... Post release, >>> there is syncing to the maven repo, updating confluence, some JIRA admin >>> things, etc.... Basically, a few hours ahead of the build, an hour to >>> build, three days for the vote, and a few hours afterword. Anyway, if anyone >>> is interested, speak up. I'd be happy to look over your virtual shoulder >>> while you do the stuff to make sure it's all done right. Not a problem. >>> >>> Thanks! >>> >>> >>> >> >> >> >
