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 > > > > > >
