It's a good idea to postpone the release and work on fixing the issues first.
On 2 July 2012 00:09, Chris Geer <[email protected]> wrote: > On Sun, Jul 1, 2012 at 2:54 PM, Ate Douma <[email protected]> wrote: > > > On 06/30/2012 05:25 PM, Franklin, Matthew B. wrote: > > > >> Unfortunately, I found a pretty big bug. When we cut over to the new > >> interface model, the rave-shindig classes began using the username as > the > >> opensocial id (similar to igoogle,etc) rather than the arbitrary > database > >> entity id. Unfortunately, when I made those changes, I didn't update > the > >> security token classes in rave portal. This means that any code in > shindig > >> that checks the security token id against the passed in userid will > fail. > >> This primarily affects appdata; which, IMO is a pretty big deal.. > >> > >> Apologies, but when you consider this with Ate's potential bug, I am not > >> sure we should ship the release... > >> > > > > Matt, thanks for finding and reporting this. I agree this seems like a > > rather serious bug. > > > > I haven't had time yet over the weekend to dive deeper into RAVE-708 but > > will try to find time for it coming days. > > > > The merge of the model interfaces changes, the upgrade to OpenJPA 2.2.0, > > and on top of that, the upgrade to shindig 2.5.0-beta2, all happened in > the > > last week. Overall this release gives me a bit uneasy feeling of being > > (too) unstable/unreliable and certainly as not enough tested. > > > > I'd like to hear others opinion on it, but I'm currently inclined to say > > we should hold off/cancel shipping this release. > > > > Maybe we should take the coming weeks to better validate and fix/improve > > the quality and reliability instead of keep rushing in more major > changes. > > As well as JIRA could use a bit of scrubbing and cleaning up of > > old/outstanding issues I think. > > > > We are also entering the summer holiday period (I myself will be 3 weeks > > away after next week) so maybe we should anticipate a bit slower progress > > anyway or at least lesser time or eyes available for properly review and > > test major changes. > > > > All in all, I'm hesitant to push out a lesser tested/validated 0.13 > > (unlucky?) version out. > > > > WDYT? > > > I don't have a problem delaying this release. If there are some features > people really want from a non-SNAPSHOT version we could always tag this as > 0.13-RC1 or something like that since it does have a lot of good stuff in > it. I guess it depends on the length of the delay. Two things I'd like to > see happening are expanding both Jasmine and integration tests. It would be > nice if we could get automated test coverage for the issues we found this > go around. > > On that note, I've been looking into the Jasmine tests and have hit a snag. > I'd like to have more of the jQuery capabilities available in the tests, in > case we want to use more of jQuery in Rave. Right now we are stubbing out > the $ variable with just the bare minimum of what we need. Is there a way > we can use the real jQuery library and just overwrite the things we need to > tweak? > > Chris > > > > > > > > > > >> -----Original Message----- > >>> From: Ate Douma [mailto:[email protected]] > >>> Sent: Friday, June 29, 2012 7:43 PM > >>> To: [email protected] > >>> Subject: [DISCUSS] Apache Rave 0.13 Release Candidate > >>> > >>> Discussion thread for vote on 0.13 release candidate. > >>> > >>> For more information on the release process, checkout - > >>> http://www.apache.org/dev/**release.html< > http://www.apache.org/dev/release.html> > >>> > >>> Some of the things to check before voting are: > >>> - can you run the demo binaries > >>> - can you build the contents of source-release.zip and svn tag > >>> - do all of the staged jars/zips contain the required LICENSE and > NOTICE > >>> files > >>> - are all of the staged artifacts signed and the signature verifiable > >>> - is the signing key in the project's KEYS file and on a public server > >>> > >> > > > > >
