On Tue, Jul 2, 2013 at 12:44 PM, Erin Noe-Payne <[email protected]>wrote:
> I can probably find time to test and perform the release this week. > > If we could update the docs at > http://rave.apache.org/release-process.html to reflect the he release > scripts we have available at > https://svn.apache.org/repos/asf/rave/release-management/ that would > be helpful to me. I performed the last release but only sort of > remember how to do it. Ha... > I will do this today. Also, I found a problem in the requirejs branch. Apparently, the shindig javascript is being pulled from the same host as the rave instance and not the shindig host. This means when I deploy Shindig to a different host, any OpenSocial gadget fails to render. > > On Tue, Jul 2, 2013 at 12:43 PM, Chris Geer <[email protected]> wrote: > > On Tue, Jul 2, 2013 at 9:37 AM, Matt Franklin <[email protected] > >wrote: > > > >> On Mon, Jul 1, 2013 at 3:36 PM, Erin Noe-Payne < > [email protected] > >> >wrote: > >> > >> > Also, to your comments Sean - I assume you are referring to 0.22 and > >> > 0.23-SNAPSHOT? > >> > > >> > In general I don't like the idea of worrying about pushing breaking > >> > changes into the trunk because of people relying on snapshot. > >> > Production systems shouldn't be depending on nightly builds, right? > >> > > >> > >> Shouldn't & are are two different things. Do any of you who would like > to > >> spin a release have time to validate trunk today? If everything checks > >> out, I am +1 for release and then merge this week. > >> > >> If trunk is not releasable though, I say lets delay a month and release > >> with require js. > >> > > > > If someone can do the release I'm definitely +1 for a release prior to > > merge. There isn't much in there that is done but there are a couple good > > bug fixes. > > > > Chris > > > >> > >> > >> > > >> > On Mon, Jul 1, 2013 at 1:25 PM, Erin Noe-Payne < > [email protected] > >> > > >> > wrote: > >> > > Ok. Are we ready to release 0.22? I'm fine with release first, but > I'd > >> > like > >> > > to get require into trunk relatively soon so we can take advantage > of > >> it, > >> > > and also so that we can keep the require, angular branches and trunk > >> all > >> > > fairly in sync. > >> > > > >> > > > >> > > On Monday, July 1, 2013, Sean Cooper wrote: > >> > >> > >> > >> +1 > >> > >> > >> > >> This will save anyone that is using 0.21 SNAPSHOT. Release 0.22 > and > >> > then > >> > >> merge onto 0.22 SNAPSHOT > >> > >> > >> > >> -Sean > >> > >> > >> > >> > >> > >> On Mon, Jul 1, 2013 at 12:03 PM, Jasha Joachimsthal > >> > >> <[email protected]>wrote: > >> > >> > >> > >> > It's been 2 months since the last release. Let's do a 0.22 > release > >> > first > >> > >> > with the bug fixes and improvements. After the release merge the > >> > require > >> > >> > branch into trunk and document how to migrate existing > >> installations. > >> > >> > > >> > >> > Jasha > >> > >> > > >> > >> > On 1 July 2013 16:38, Matt Franklin <[email protected]> > >> wrote: > >> > >> > > >> > >> > > IMO, latter; but, I would allow 72 hrs for lazy consensus > review. > >> > >> > > > >> > >> > > Other opinions? > >> > >> > > > >> > >> > > On Monday, July 1, 2013, Erin Noe-Payne wrote: > >> > >> > > > >> > >> > > > Hi All, > >> > >> > > > > >> > >> > > > The require.js branch is nearing completion, and I expect it > >> will > >> > be > >> > >> > > > ready to bring back into trunk within the next day or two. > >> Should > >> > >> > > > the > >> > >> > > > merge be submitted as a patch through the review board, or > >> should > >> > I > >> > >> > > > just go ahead with it when it is ready, and provide an 0.21 > -> > >> > 0.22 > >> > >> > > > guide? > >> > >> > > > > >> > >> > > > On Thu, Jun 20, 2013 at 5:20 PM, Erin Noe-Payne > >> > >> > > > <[email protected]> wrote: > >> > >> > > > > Hey all, just to be clear since Dan's patch created a bit > of > >> > >> > confusion > >> > >> > > > > - I created a "require" branch for this task. Since this > is a > >> > >> > > > > pretty > >> > >> > > > > broad change I felt we needed a branch to collaborate and > >> > complete > >> > >> > the > >> > >> > > > > changes. I am expecting a number of patches to be submitted > >> > >> > > > > against > >> > >> > it > >> > >> > > > > in the next couple weeks. > >> > >> > > > > > >> > >> > > > > Let me know if there are any concerns. > >> > >> > > > > > >> > >> > > > > On Wed, Jun 19, 2013 at 6:43 PM, Matt Franklin < > >> > >> > > [email protected]> > >> > >> > > > wrote: > >> > >> > > > >> On Wed, Jun 19, 2013 at 10:25 AM, Chris Geer > >> > >> > > > >> <[email protected] > >> > >> > > > >> > >> > > > wrote: > >> > >> > > > >> > >> > >> > > > >>> On Wed, Jun 19, 2013 at 6:28 AM, Erin Noe-Payne < > >> > >> > > > [email protected] > >> > >> > > > >>> >wrote: > >> > >> > > > >>> > >> > >> > > > >>> > Specifically, the idea of require js is to take all > >> > references > >> > >> > off > >> > >> > > of > >> > >> > > > >>> > the global namespace and to build out and resolve a > >> > dependency > >> > >> > tree > >> > >> > > > >>> > for your client side code. So if we made it optional, > >> then > >> > >> > someone > >> > >> > > > >>> > who wanted to take advantage of the feature would need > to > >> > >> > > > >>> > overlay > >> > >> > > any > >> > >> > > > >>> > place where there is a reference to the global rave > >> object. > >> > >> > > > >>> > That > >> > >> > > > >>> > includes jsps where there is a script block that uses > >> > rave.*, > >> > >> > > > >>> > and > >> > >> > > > wrap > >> > >> > > > >>> > that in a require block. You would also need to overlay > >> the > >> > >> > > > >>> > java > >> > >> > > > class > >> > >> > > > >>> > that inserts rave.registerWidget(...) onto the page and > >> wrap > >> > >> > those > >> > >> > > in > >> > >> > > > >>> > require blocks. Also any jsp that has an > onclick="rave.*" > >> > >> > > > >>> > event > >> > >> > > > >>> > handler, those would need to be moved to jquery > bindings > >> and > >> > >> > > wrapped > >> > >> > > > >>> > in require blocks. Once you had that you would overlay > the > >> > >> > > > >>> > rave_script.js tag so that instead of link all the > >> scripts, > >> > >> > > > >>> > you > >> > >> > > just > >> > >> > > > >>> > reference require.js with a data-main attribute > pointing > >> to > >> > >> > > > >>> > your > >> > >> > > > >>> > bootstrapping script. (See > >> > >> > > > >>> > http://requirejs.org/docs/start.html > >> > >> > ). > >> > >> > > > >>> > > >> > >> > > > >>> > If instead we make a breaking change, then we would do > all > >> > of > >> > >> > > > >>> > the > >> > >> > > > >>> > above work on trunk. An implementer who wanted to go to > >> 0.22 > >> > >> > would > >> > >> > > > >>> > then be responsible for updating their scripts to be > >> written > >> > >> > > > >>> > as > >> > >> > AMD > >> > >> > > > >>> > modules (http://requirejs.org/docs/api.html#define). > The > >> > >> > > > >>> > script > >> > >> > is > >> > >> > > > >>> > >> > > >> >
