Alex seems to be the official release-maker at this point. I would be in favor of a 1.3.5 release (actually, I think we had settled on jumping to 1.4). Before we do though, I think we should probably decide which (if any) of my unmerged branches (listed earlier in the thread) should be pulled into the trunk/. Obviously, I would love to see *everything* I do automatically make it into the mainline, so someone else needs to make this decision. :-)
Daniel On Wed, Sep 16, 2009 at 9:31 AM, 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. > > > 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 >>>>>> >>>>>> >>>>> >>>> >>> >
