On Wed, Sep 16, 2009 at 17:51, Antoine Toulme <[email protected]>wrote:
> > > On Wed, Sep 16, 2009 at 16:31, Rhett Sutphin <[email protected]>wrote: > >> Hi all, >> >> On Sep 16, 2009, at 9:22 AM, Antoine Toulme wrote: >> >> Can we reactive this discussion ? >>> I note rjb issued a new release to support Snow Leopard. >>> http://rubyforge.org/forum/forum.php?forum_id=34590 >>> >>> If it's ok, I can try it out, see if all specs pass with it ? >>> >> >> I believe Assaf's already updated trunk with the new version of rjb. >> > He updated to 1.1.8, 1.1.9 got out since. Not sure of the difference. > Sorry for the noise, I was wrong. I missed the commit in the feed. Thanks, Antoine > >> >> http://markmail.org/search/?q=buildr%20snow%20leopard#query:buildr%20snow%20leopard+page:1+mid:cux73pnn5qr5vxi3+state:results >> >> Then it would be time to consider doing a release, what do you think ? >>> >>> What more can I do to help with it ? >>> >> >> It would be nice to have an officially-released Snow Leopard-compatible >> buildr 1.3.5. I'd also like to offer any assistance I can. >> >> Thanks, >> Rhett >> >> >> >> >>> Thanks, >>> >>> Antoine >>> >>> >>> On Thu, Aug 20, 2009 at 22:35, Daniel Spiewak <[email protected]> >>> wrote: >>> >>> I vote that we should defer the release until September. That'll give >>>> all >>>> of us more time to get our stuff in order. We also need to decide which >>>> of >>>> my forks and knives to try to get into 1.4.0 (I vote for documentation >>>> support). Whatever we choose, I just don't see us able to get a solid >>>> release ready in the next week given the current commitments of the core >>>> developers. >>>> >>>> Daniel >>>> >>>> On Thu, Aug 20, 2009 at 3:30 PM, Alex Boisvert <[email protected]> >>>> wrote: >>>> >>>> Sorry devs, I won't be able to tackle the 1.4 release before I leave >>>>> for >>>>> vacation. I haven't managed to tame my work pile and I don't think it >>>>> >>>> would >>>> >>>>> be advisable to make a release and disappear the next day. (I'm going >>>>> to >>>>> pretend they don't have Internet on the island where I'm going) >>>>> >>>>> Feel free to release during my absence... otherwise I'll be back to >>>>> this >>>>> around Sept. 7th. >>>>> >>>>> alex >>>>> >>>>> >>>>> On Tue, Aug 4, 2009 at 8:26 PM, Daniel Spiewak <[email protected]> >>>>> wrote: >>>>> >>>>> I agree: we should start thinking about a release in the near future. >>>>>> >>>>> I >>>> >>>>> also agree that we should probably call it 1.4.0 rather than 1.3.5, >>>>>> reflecting the fact that we have added some interesting new features >>>>>> >>>>> (shell >>>>> >>>>>> support, cleanup and polish of Scala features, cobertura:check, etc). >>>>>> >>>>>> The most important step in getting us to 1.4.0 would be checking up on >>>>>> >>>>> our >>>>> >>>>>> faithful specs and making sure that everything is passing >>>>>> (particularly >>>>>> >>>>> on >>>>> >>>>>> JRuby, given the extensive monkey patching we did in that department). >>>>>> >>>>> It >>>>> >>>>>> would also be very nice to spec out the shell support, at least a >>>>>> >>>>> little >>>> >>>>> bit. In that vein, the shell API needs to be reorganized *slightly* >>>>>> >>>>> before >>>>> >>>>>> we make a release, bringing it more in line with the test and compiler >>>>>> >>>>> APIs >>>>> >>>>>> (extend Rake::Task, etc). That's pretty minor though, and wouldn't >>>>>> >>>>> break >>>> >>>>> any of the existing providers. >>>>>> >>>>>> As for my pending silverware... :-) I've got two significant >>>>>> features >>>>>> that >>>>>> I would *really* like to bring into the core at some point, preferably >>>>>> sooner rather than later. Unfortunately, I have run out of time to >>>>>> actually >>>>>> see these through (at least in the near future). These two features: >>>>>> >>>>>> - Continuous compilation (branch: continuous-compilation) >>>>>> - A generic documentation framework (branch: doc-framework) >>>>>> >>>>>> Both of these can be found in my Git fork: git:// >>>>>> github.com/djspiewak/buildr.git Unfortunately, as is typical of my >>>>>> >>>>> work >>>> >>>>> on >>>>>> Buildr, neither of them have working specs. :-) I've tried to spec >>>>>> >>>>> out >>>> >>>>> continuous-compilation, but I ran into some serious difficulties with >>>>>> RSpec's mocking framework. Help here would be appreciated! >>>>>> >>>>>> Continuous compilation is actually a remarkably simple extension, only >>>>>> about >>>>>> 80 or so lines of pretty straightforward Ruby. The only thing it's >>>>>> >>>>> lacking >>>>> >>>>>> right now (besides specs) is the ability to recursively monitor >>>>>> sub-projects. This would be very easy for someone else to add though, >>>>>> >>>>> just >>>>> >>>>>> fiddle with lib/buildr/core/cc.rb and you should be golden. >>>>>> >>>>>> The really interesting change (I think) is the generic doc framework. >>>>>> >>>>> This >>>>> >>>>>> attempts to address a glaring weakness in Buildr's multi-language >>>>>> >>>>> support: >>>>> >>>>>> documentation generation. Right now, Buildr has very convenient >>>>>> >>>>> support >>>> >>>>> for >>>>>> Javadoc (through the javadoc task), but no support for Scaladoc, >>>>>> >>>>> VScaladoc >>>>> >>>>>> or Groovydoc. My doc-framework branch removes the javadoc task (with >>>>>> deprecation) and replaces it with a more generic doc task. This task >>>>>> detects the relevant doc gen provider based on the project language, >>>>>> >>>>> then >>>> >>>>> uses it to generate documentation in the _(:target, :doc) directory. >>>>>> >>>>> It >>>> >>>>> also includes support for overriding the default doc gen provider (e.g. >>>>>> >>>>> use >>>>> >>>>>> :vscaladoc instead of the default on a Scala project). This is >>>>>> missing >>>>>> specs, documentation and actual support for Groovydoc (should be a few >>>>>> minutes of work, especially for someone who knows the Groovydoc API). >>>>>> Unlike continuous-compilation or interactive-shell, the generic doc >>>>>> framework should be quite straightforward to spec out and even easier >>>>>> >>>>> to >>>> >>>>> document. >>>>>> >>>>>> If I had to choose between the two, I would really like to get the >>>>>> documentation framework into the core before we make a release. >>>>>> >>>>> However, >>>> >>>>> continuous compilation support is a lot closer to completion, so it >>>>>> >>>>> might >>>> >>>>> be >>>>>> wiser to focus on it. Alternatively, we could push back the release >>>>>> >>>>> still >>>>> >>>>>> further and try to get them both in. This would give us even more of >>>>>> >>>>> an >>>> >>>>> excuse to call it "1.4.0", but it does of course mean a longer delay. >>>>>> >>>>>> The big problem I have right now is that I just don't have time to >>>>>> >>>>> follow >>>> >>>>> up >>>>>> with any of these pending tasks. I'll do what I can, but I doubt I'll >>>>>> >>>>> be >>>> >>>>> able to put as much into Buildr as I have been in recent months. >>>>>> >>>>>> Daniel >>>>>> >>>>>> On Tue, Aug 4, 2009 at 7:42 PM, Alex Boisvert <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Buildrs, >>>>>>> >>>>>>> Our last release was back in April... Given that we have plenty of >>>>>>> improvements and fixes to justify a release, I think we should >>>>>>> >>>>>> mentally >>>> >>>>> prepare releasing before the end of August. I was thinking of >>>>>>> >>>>>> shooting >>>>> >>>>>> for >>>>>>> the 18-19th since I'll be away on vacation 2 weeks after the 22nd. >>>>>>> >>>>>> What >>>>>> >>>>>>> do you think? >>>>>>> >>>>>>> On my list... I'll start reviewing outstanding issues and maybe >>>>>>> >>>>>> tackle >>>> >>>>> a >>>>> >>>>>> few >>>>>>> easy ones. I've also been working on the Rake <-> Buildr tutorial >>>>>>> >>>>>> which >>>>>> >>>>>>> should be ready by that time. >>>>>>> >>>>>>> Anything on your list? There's also the question of whether we want >>>>>>> >>>>>> to >>>>> >>>>>> release 1.3.5 or rather make it 1.4.0. I personally don't have a >>>>>>> >>>>>> strong >>>>> >>>>>> preference either way. I think 1.4.0 would be a nice prop for the >>>>>>> interactive shell support. And even more so if we can squeeze other >>>>>>> >>>>>> things >>>>>> >>>>>>> from Daniel's ever-growing tray of forks and knives ;) >>>>>>> >>>>>>> alex >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >
