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 ? Then it would be time to consider doing a release, what do you think ? What more can I do to help with it ? 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 > > > > > > > > > >
