On 2 July 2012 10:53, Ate Douma <[email protected]> wrote: > On 07/02/2012 10:00 AM, Jasha Joachimsthal wrote: > >> It's a good idea to postpone the release and work on fixing the issues >> first. >> > > While I agree on the latter, I'm not sure we should postpone the release > (0.13). > > As we're striving for a release every month I'd rather cancel/skip the > 0.13 release and focus on fixing the trunk (0.14-SNAPSHOT) instead so we > hopefully have a more stable and reliable 0.14 release end of this month. > > Postponing 0.13 would mean creating a separate branch based on the 0.13 > tag and working towards a 0.13.1 release candidate (note that a 0.13-RC1 as > Chris proposed isn't really an option anymore as 0.13 already has been > tagged). > > All this seems like unnecessary extra work to me, unless some major other > changes were planned/targeted for trunk which cannot wait. > Instead, I propose canceling the 0.13 release and work towards a better > 0.14 release instead. > > Ate > > I'm okay with skipping the release and continue towards a stable 0.14 at the end of the month. Whoever wants a sticky revision can refer to the 0.13 tag and create the artifacts themselves.
> > >> 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> >>>>>> < >>>>>> >>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >
