You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Antoine Toulme <an...@lunar-ocean.com> on 2010/04/01 09:04:42 UTC
Buildr 1.4.0 RC1
Hi, the first RC for Buildr 1.4.0 is available here:
http://people.apache.org/~toulmean/buildr/1.4.0
Now is the time for testing. In two weeks, we will issue a GA release if
everything is smooth.
Thanks!
Antoine
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Specs pass again:
the problem was that the scala version was set, and the build settings were
not overridable in the specs afterwards.
I moved the scala version setting as a before(:each) block for the scala
specs.
I could not find a better way to do this, for now. Feel free to rework it,
as long as specs pass.
I'm looking forward to getting a CI build so that we can detect those
problems early.
Antoine
On Sun, Apr 11, 2010 at 14:53, Alex Boisvert <al...@gmail.com>wrote:
> On Sat, Apr 10, 2010 at 11:28 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>> We're down to 5 open issues.
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310734&fixfor=12313152&resolution=-1&sorter/field=priority&sorter/order=DESC
>>
>
> BTW, I've reported the issue about ScalaTest + Specs/ScalaCheck here:
>
> http://groups.google.com/group/scalatest-users/browse_thread/thread/a429b4adf551278d#
> and waiting for an updated release of ScalaTest.
>
> (I can't comment on Jira right now since it was hacked earlier this week;
> waiting for my account to be reenabled).
>
> alex
>
>
Re: Integrating with JPackage
Posted by Adam Young <ay...@redhat.com>.
On 04/19/2010 04:08 PM, Antoine Toulme wrote:
> On Mon, Apr 19, 2010 at 12:35, Adam Young<ay...@redhat.com> wrote:
>
>
>> On 04/19/2010 01:31 PM, Antoine Toulme wrote:
>>
>>
>>> A couple of quick comments while reading your gist:
>>>
>>>
>>>
>> Thanks for the feed back. THis is "proof-of-concept" code, that will make
>> it possible to build, but certainly not ready for prime time.
>>
>>
>> You should avoid at all costs using global variables with $. In practice,
>>
>>> it
>>> is best to use a singleton approach.
>>>
>>>
>>>
>> There is a difference between a global variable and a a singleton. In this
>> case, the difference is academic, but In general is is poor design to use a
>> Class name as the way to locate an instance variable.
>>
>>
> Sure. Actually here you could maybe even be safe with a @field ? I would
> need specs to back that.
>
THat sounds about right. I'll ty it out.
>
>> In this case, it would more likely make sense for there to be some variable
>> at the module scope, but I have to admit that my ruby is fresh enough that I
>> don't know how to do this off the top of my head, or if Ruby even allows
>> such a thing. A better solution would be to make the repository itself an
>> object and the parsing to be part of the construction of the repo object.
>> Or something.
>>
>>
>> Use info, warn, error to log stuff.
>>
>>>
>>>
>> Yeah. Still developing this. puts is this poor man's debugger.
>>
>>
>> If you need to check that an object is nil, you can do object.nil?
>>
>>>
>>>
>> Thanks. That is a new rubiysm for me. I like the ability to avoid
>> accidental assignment.
>>
>> Last but actually the most important item, we need specs to integrate
>>
>>> those
>>> changes. For the first gist, a couple of specs demonstrating that you can
>>> monkey patch successfully the Repositories instance would be great. For
>>> the
>>> module itself, it'd be great for you to have specs to deal with the
>>> absence
>>> of the xml file, malformed file, etc.
>>>
>>>
>>>
>> specs? That word means a few different things to me, but I suspect it
>> means something specific here. Can you send me a pointer?
>>
> Check out rspec, and the spec folder under the buildr code.
> It helps you define what the code is intended for and avoid breaking it by
> mistake.
> It's almost a test unit - there is a specification aspect to the way you
> write them.
>
Sounds good. I'll check it out. I like the idea of something checking
my work for me.
>
>>
>> I think we would be interested into this extension to be part of Buidr
>>
>>> itself. I would recommend that people interested by this functionality do
>>> an
>>> extra require in their Buildfile: require "buildr/jpp" for example, much
>>> like you do an extra require to add ecj as a compiler today.
>>>
>>>
>>>
>> I'm almost tempted to say that it should be a switch to buildr itself as
>> opposed to a change to the buildfile. Chosing which repository scheme to
>> use is a distribution decsion, one that may not be mirrored by the people
>> writing the code that gets distributed. WHile in Candlepin we do have the
>> ability to dictate which version of buildr to use for our purposes, we have
>> the goal that one should not need JPackage to build, or even that the end
>> use is building on Fedora or even Linux.
>>
>>
> In your buildfile, you will always assume you are using jpp dependencies,
> correct ? Since you are going to name repositories anyway.
> So doing a require at the top of the Buildfile sounds like the right
> approach to me.
>
No, there will be no dep in the buildfile. THe buildfile will list the
Java dependencies, but, unless you build with the switch, it will
resolve the dependencies the way that buildr and maven do today: based
on the values set via
repositories.remote=
What the JPP approach would do would override that and set
repositories.remote=file:///usr/share/maven
For stricter builds.
But yes, you could force your porject to build this way if you really
wanted to. I think the switch approach would be required.
>
>
>> mvn-jpp is run a a wrapper that just call mvn with a couple of switches:
>>
>> -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars
>>
>> I'm tempted to say that buildr should implement at least the last two as
>> switches.
>>
>>
> We can also do that.
>
>
>> In building the hash for jar to version, I'm currently adding two keys for
>> each package: One with the version info and one without. Ideally, we'd
>> allow multiple versions in JPP, and not have to use
>> -Dmaven2.ignore.versions.
>>
>> So perhaps we could allow a switch which is buildr --usejpp
>>
> OK. But really --usejpp would be the same as writing "require 'buildr/jpp'".
> I am certainly missing something, but I think we have a good agreement. And
> if we have 2 ways to do the same thing, I tend to like it.
>
>
>>
>>
>> Thanks for your interest in Buildr!
>>
>>> Antoine
>>>
>>>
>>> On Mon, Apr 19, 2010 at 10:23, Adam Young<ay...@redhat.com> wrote:
>>>
>>>
>>>
>>>
>>>> We have been happily using builder for For the Candlepin project fora few
>>>> months now. As we get closer to "productization" I've been looking into
>>>> a
>>>> way to build the project from sources, to include all of the
>>>> dependencies.
>>>> Dependencies downloaded from the Maven repositories are often based at
>>>> some
>>>> point on checked-in binaries. An alternative approach, and the which is
>>>> embraced by JPackage, is to:
>>>>
>>>> A) Create Source level RPMS for all dependencies and
>>>> B) Create local maven repo out of those jars.
>>>>
>>>> This is the approach I've been pursuing, and so far, so good. In order
>>>> to
>>>> take advantage of this approach, I've had to modify my version of builder
>>>> as
>>>> well as call builder with an additional module. The change to buildr
>>>> proper
>>>> allows the local module to overload how the repository path is built:
>>>>
>>>> http://gist.github.com/368958
>>>>
>>>> This creates a module level function named build_path with the existing
>>>> logic.
>>>>
>>>> My overloaded version goes into a local script I am createivle calling
>>>> ./localbuild.rb.
>>>>
>>>> Here's a first draft.
>>>>
>>>> http://gist.github.com/371298
>>>>
>>>>
>>>> Note that this version redefines build_path.
>>>>
>>>> I used libxml to parse the maven repository mapping file, because
>>>> xmlsimple
>>>> was flaking out on me. I'm sure I could have debugged it further, but
>>>> instead I went with what seems to be a faster and simpler approach using
>>>> streaming.
>>>>
>>>>
>>>> This page explains the Maven version of JPP, and the rules buildr needs
>>>> to
>>>> follow to make use of the JPP approach.
>>>>
>>>> http://fedoraproject.org/wiki/Java/JPPMavenReadme
>>>>
>>>> Is there other interest in this approach?
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
Re: Integrating with JPackage
Posted by Antoine Toulme <an...@lunar-ocean.com>.
On Mon, Apr 19, 2010 at 12:35, Adam Young <ay...@redhat.com> wrote:
> On 04/19/2010 01:31 PM, Antoine Toulme wrote:
>
>> A couple of quick comments while reading your gist:
>>
>>
>
> Thanks for the feed back. THis is "proof-of-concept" code, that will make
> it possible to build, but certainly not ready for prime time.
>
>
> You should avoid at all costs using global variables with $. In practice,
>> it
>> is best to use a singleton approach.
>>
>>
>
> There is a difference between a global variable and a a singleton. In this
> case, the difference is academic, but In general is is poor design to use a
> Class name as the way to locate an instance variable.
>
Sure. Actually here you could maybe even be safe with a @field ? I would
need specs to back that.
>
> In this case, it would more likely make sense for there to be some variable
> at the module scope, but I have to admit that my ruby is fresh enough that I
> don't know how to do this off the top of my head, or if Ruby even allows
> such a thing. A better solution would be to make the repository itself an
> object and the parsing to be part of the construction of the repo object.
> Or something.
>
>
> Use info, warn, error to log stuff.
>>
>>
> Yeah. Still developing this. puts is this poor man's debugger.
>
>
> If you need to check that an object is nil, you can do object.nil?
>>
>>
> Thanks. That is a new rubiysm for me. I like the ability to avoid
> accidental assignment.
>
> Last but actually the most important item, we need specs to integrate
>> those
>> changes. For the first gist, a couple of specs demonstrating that you can
>> monkey patch successfully the Repositories instance would be great. For
>> the
>> module itself, it'd be great for you to have specs to deal with the
>> absence
>> of the xml file, malformed file, etc.
>>
>>
> specs? That word means a few different things to me, but I suspect it
> means something specific here. Can you send me a pointer?
Check out rspec, and the spec folder under the buildr code.
It helps you define what the code is intended for and avoid breaking it by
mistake.
It's almost a test unit - there is a specification aspect to the way you
write them.
>
>
> I think we would be interested into this extension to be part of Buidr
>> itself. I would recommend that people interested by this functionality do
>> an
>> extra require in their Buildfile: require "buildr/jpp" for example, much
>> like you do an extra require to add ecj as a compiler today.
>>
>>
> I'm almost tempted to say that it should be a switch to buildr itself as
> opposed to a change to the buildfile. Chosing which repository scheme to
> use is a distribution decsion, one that may not be mirrored by the people
> writing the code that gets distributed. WHile in Candlepin we do have the
> ability to dictate which version of buildr to use for our purposes, we have
> the goal that one should not need JPackage to build, or even that the end
> use is building on Fedora or even Linux.
>
In your buildfile, you will always assume you are using jpp dependencies,
correct ? Since you are going to name repositories anyway.
So doing a require at the top of the Buildfile sounds like the right
approach to me.
>
> mvn-jpp is run a a wrapper that just call mvn with a couple of switches:
>
> -Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars
>
> I'm tempted to say that buildr should implement at least the last two as
> switches.
>
We can also do that.
>
> In building the hash for jar to version, I'm currently adding two keys for
> each package: One with the version info and one without. Ideally, we'd
> allow multiple versions in JPP, and not have to use
> -Dmaven2.ignore.versions.
>
> So perhaps we could allow a switch which is buildr --usejpp
OK. But really --usejpp would be the same as writing "require 'buildr/jpp'".
I am certainly missing something, but I think we have a good agreement. And
if we have 2 ways to do the same thing, I tend to like it.
>
>
>
> Thanks for your interest in Buildr!
>>
>> Antoine
>>
>>
>> On Mon, Apr 19, 2010 at 10:23, Adam Young<ay...@redhat.com> wrote:
>>
>>
>>
>>> We have been happily using builder for For the Candlepin project fora few
>>> months now. As we get closer to "productization" I've been looking into
>>> a
>>> way to build the project from sources, to include all of the
>>> dependencies.
>>> Dependencies downloaded from the Maven repositories are often based at
>>> some
>>> point on checked-in binaries. An alternative approach, and the which is
>>> embraced by JPackage, is to:
>>>
>>> A) Create Source level RPMS for all dependencies and
>>> B) Create local maven repo out of those jars.
>>>
>>> This is the approach I've been pursuing, and so far, so good. In order
>>> to
>>> take advantage of this approach, I've had to modify my version of builder
>>> as
>>> well as call builder with an additional module. The change to buildr
>>> proper
>>> allows the local module to overload how the repository path is built:
>>>
>>> http://gist.github.com/368958
>>>
>>> This creates a module level function named build_path with the existing
>>> logic.
>>>
>>> My overloaded version goes into a local script I am createivle calling
>>> ./localbuild.rb.
>>>
>>> Here's a first draft.
>>>
>>> http://gist.github.com/371298
>>>
>>>
>>> Note that this version redefines build_path.
>>>
>>> I used libxml to parse the maven repository mapping file, because
>>> xmlsimple
>>> was flaking out on me. I'm sure I could have debugged it further, but
>>> instead I went with what seems to be a faster and simpler approach using
>>> streaming.
>>>
>>>
>>> This page explains the Maven version of JPP, and the rules buildr needs
>>> to
>>> follow to make use of the JPP approach.
>>>
>>> http://fedoraproject.org/wiki/Java/JPPMavenReadme
>>>
>>> Is there other interest in this approach?
>>>
>>>
>>>
>>
>>
>
>
Re: Integrating with JPackage
Posted by Adam Young <ay...@redhat.com>.
On 04/19/2010 01:31 PM, Antoine Toulme wrote:
> A couple of quick comments while reading your gist:
>
Thanks for the feed back. THis is "proof-of-concept" code, that will
make it possible to build, but certainly not ready for prime time.
> You should avoid at all costs using global variables with $. In practice, it
> is best to use a singleton approach.
>
There is a difference between a global variable and a a singleton. In
this case, the difference is academic, but In general is is poor design
to use a Class name as the way to locate an instance variable.
In this case, it would more likely make sense for there to be some
variable at the module scope, but I have to admit that my ruby is fresh
enough that I don't know how to do this off the top of my head, or if
Ruby even allows such a thing. A better solution would be to make the
repository itself an object and the parsing to be part of the
construction of the repo object. Or something.
> Use info, warn, error to log stuff.
>
Yeah. Still developing this. puts is this poor man's debugger.
> If you need to check that an object is nil, you can do object.nil?
>
Thanks. That is a new rubiysm for me. I like the ability to avoid
accidental assignment.
> Last but actually the most important item, we need specs to integrate those
> changes. For the first gist, a couple of specs demonstrating that you can
> monkey patch successfully the Repositories instance would be great. For the
> module itself, it'd be great for you to have specs to deal with the absence
> of the xml file, malformed file, etc.
>
specs? That word means a few different things to me, but I suspect it
means something specific here. Can you send me a pointer?
> I think we would be interested into this extension to be part of Buidr
> itself. I would recommend that people interested by this functionality do an
> extra require in their Buildfile: require "buildr/jpp" for example, much
> like you do an extra require to add ecj as a compiler today.
>
I'm almost tempted to say that it should be a switch to buildr itself as
opposed to a change to the buildfile. Chosing which repository scheme
to use is a distribution decsion, one that may not be mirrored by the
people writing the code that gets distributed. WHile in Candlepin we do
have the ability to dictate which version of buildr to use for our
purposes, we have the goal that one should not need JPackage to build,
or even that the end use is building on Fedora or even Linux.
mvn-jpp is run a a wrapper that just call mvn with a couple of switches:
-Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars
I'm tempted to say that buildr should implement at least the last two as
switches.
In building the hash for jar to version, I'm currently adding two keys
for each package: One with the version info and one without. Ideally,
we'd allow multiple versions in JPP, and not have to use
-Dmaven2.ignore.versions.
So perhaps we could allow a switch which is buildr --usejpp
> Thanks for your interest in Buildr!
>
> Antoine
>
>
> On Mon, Apr 19, 2010 at 10:23, Adam Young<ay...@redhat.com> wrote:
>
>
>> We have been happily using builder for For the Candlepin project fora few
>> months now. As we get closer to "productization" I've been looking into a
>> way to build the project from sources, to include all of the dependencies.
>> Dependencies downloaded from the Maven repositories are often based at some
>> point on checked-in binaries. An alternative approach, and the which is
>> embraced by JPackage, is to:
>>
>> A) Create Source level RPMS for all dependencies and
>> B) Create local maven repo out of those jars.
>>
>> This is the approach I've been pursuing, and so far, so good. In order to
>> take advantage of this approach, I've had to modify my version of builder as
>> well as call builder with an additional module. The change to buildr proper
>> allows the local module to overload how the repository path is built:
>>
>> http://gist.github.com/368958
>>
>> This creates a module level function named build_path with the existing
>> logic.
>>
>> My overloaded version goes into a local script I am createivle calling
>> ./localbuild.rb.
>>
>> Here's a first draft.
>>
>> http://gist.github.com/371298
>>
>>
>> Note that this version redefines build_path.
>>
>> I used libxml to parse the maven repository mapping file, because xmlsimple
>> was flaking out on me. I'm sure I could have debugged it further, but
>> instead I went with what seems to be a faster and simpler approach using
>> streaming.
>>
>>
>> This page explains the Maven version of JPP, and the rules buildr needs to
>> follow to make use of the JPP approach.
>>
>> http://fedoraproject.org/wiki/Java/JPPMavenReadme
>>
>> Is there other interest in this approach?
>>
>>
>
Re: Integrating with JPackage
Posted by Antoine Toulme <an...@lunar-ocean.com>.
A couple of quick comments while reading your gist:
You should avoid at all costs using global variables with $. In practice, it
is best to use a singleton approach.
Use info, warn, error to log stuff.
If you need to check that an object is nil, you can do object.nil?
Last but actually the most important item, we need specs to integrate those
changes. For the first gist, a couple of specs demonstrating that you can
monkey patch successfully the Repositories instance would be great. For the
module itself, it'd be great for you to have specs to deal with the absence
of the xml file, malformed file, etc.
I think we would be interested into this extension to be part of Buidr
itself. I would recommend that people interested by this functionality do an
extra require in their Buildfile: require "buildr/jpp" for example, much
like you do an extra require to add ecj as a compiler today.
Thanks for your interest in Buildr!
Antoine
On Mon, Apr 19, 2010 at 10:23, Adam Young <ay...@redhat.com> wrote:
> We have been happily using builder for For the Candlepin project fora few
> months now. As we get closer to "productization" I've been looking into a
> way to build the project from sources, to include all of the dependencies.
> Dependencies downloaded from the Maven repositories are often based at some
> point on checked-in binaries. An alternative approach, and the which is
> embraced by JPackage, is to:
>
> A) Create Source level RPMS for all dependencies and
> B) Create local maven repo out of those jars.
>
> This is the approach I've been pursuing, and so far, so good. In order to
> take advantage of this approach, I've had to modify my version of builder as
> well as call builder with an additional module. The change to buildr proper
> allows the local module to overload how the repository path is built:
>
> http://gist.github.com/368958
>
> This creates a module level function named build_path with the existing
> logic.
>
> My overloaded version goes into a local script I am createivle calling
> ./localbuild.rb.
>
> Here's a first draft.
>
> http://gist.github.com/371298
>
>
> Note that this version redefines build_path.
>
> I used libxml to parse the maven repository mapping file, because xmlsimple
> was flaking out on me. I'm sure I could have debugged it further, but
> instead I went with what seems to be a faster and simpler approach using
> streaming.
>
>
> This page explains the Maven version of JPP, and the rules buildr needs to
> follow to make use of the JPP approach.
>
> http://fedoraproject.org/wiki/Java/JPPMavenReadme
>
> Is there other interest in this approach?
>
Integrating with JPackage
Posted by Adam Young <ay...@redhat.com>.
We have been happily using builder for For the Candlepin project fora
few months now. As we get closer to "productization" I've been looking
into a way to build the project from sources, to include all of the
dependencies. Dependencies downloaded from the Maven repositories are
often based at some point on checked-in binaries. An alternative
approach, and the which is embraced by JPackage, is to:
A) Create Source level RPMS for all dependencies and
B) Create local maven repo out of those jars.
This is the approach I've been pursuing, and so far, so good. In order
to take advantage of this approach, I've had to modify my version of
builder as well as call builder with an additional module. The change to
buildr proper allows the local module to overload how the repository
path is built:
http://gist.github.com/368958
This creates a module level function named build_path with the existing
logic.
My overloaded version goes into a local script I am createivle calling
./localbuild.rb.
Here's a first draft.
http://gist.github.com/371298
Note that this version redefines build_path.
I used libxml to parse the maven repository mapping file, because
xmlsimple was flaking out on me. I'm sure I could have debugged it
further, but instead I went with what seems to be a faster and simpler
approach using streaming.
This page explains the Maven version of JPP, and the rules buildr needs
to follow to make use of the JPP approach.
http://fedoraproject.org/wiki/Java/JPPMavenReadme
Is there other interest in this approach?
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
Good to know! That's still a little late for us, but certainly within the
realm of "repackage the all-in-one without telling anyone". :-)
Incidentally, I pulled the latest from the jruby-1_5 branch and everything I
tried seems to work fine. I didn't do anything even remotely comprehensive
though, it was just a bit of informal testing on my own stuff.
Daniel
On Wed, Apr 21, 2010 at 11:01 PM, Charles Oliver Nutter <headius@headius.com
> wrote:
> FYI, jruby 1.5 we'll go to rc 2 next week. After that hopefully only 1 or 2
> more weeks before final.
>
> On Apr 20, 2010 7:07 PM, "Daniel Spiewak" <dj...@gmail.com> wrote:
>
> We can either issue RC2, or we can go straight to the full release. My
> impression is that JRuby 1.5 isn't going to go GA for a while, so it's not
> worth waiting unless there's a testing advantage (like fixing those specs I
> don't understand). :-)
>
> Daniel
>
> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <antoine@lunar-ocean.com
> >wrote:
>
>
> > I'm all for it. Want to issue RC2 ? I can try again, with pygments this
> > time.
> >
> > On Sun, Apr 1...
>
Re: Buildr 1.4.0 RC1
Posted by Charles Oliver Nutter <he...@headius.com>.
FYI, jruby 1.5 we'll go to rc 2 next week. After that hopefully only 1 or 2
more weeks before final.
On Apr 20, 2010 7:07 PM, "Daniel Spiewak" <dj...@gmail.com> wrote:
We can either issue RC2, or we can go straight to the full release. My
impression is that JRuby 1.5 isn't going to go GA for a while, so it's not
worth waiting unless there's a testing advantage (like fixing those specs I
don't understand). :-)
Daniel
On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <antoine@lunar-ocean.com
>wrote:
> I'm all for it. Want to issue RC2 ? I can try again, with pygments this
> time.
>
> On Sun, Apr 1...
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
Interesting! I never knew that ssh could do that.
Daniel
On Jun 15, 2010, at 4:35 PM, "Antoine Toulme" <antoine@lunar-
ocean.com> wrote:
> Daniel, on this, here is a tidbit of wisdom from Assaf:
> In ~/.ssh/config, add:
>
> Host people.apache.org
> User <your apache user name>
>
> On Wed, Apr 21, 2010 at 21:00, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
>> You better do it. I am not privy to the words of power required to
>> cut a
>> release. That and my Apache username is different from my local
>> username,
>> so the release task doesn't work for me. :-)
>>
>> Daniel
>>
>> On Wed, Apr 21, 2010 at 10:51 PM, Antoine Toulme <antoine@lunar-ocean.com
>>> wrote:
>>
>>> I'll try to cut RC2 now, unless you're on it ?
>>>
>>> Thanks Daniel!
>>>
>>> On Wed, Apr 21, 2010 at 19:46, Daniel Spiewak <dj...@gmail.com>
>> wrote:
>>>
>>>> The issues with the specs were caused by flaky FSC. I've
>>>> rejiggered
>> the
>>>> Rake task to turn off FSC when running the spec suite (for Buildr).
>> All
>>>> the
>>>> specs are passing now, so we can go ahead and cut RC2.
>>>>
>>>> In the meantime, I'm going to grab the latest from the JRuby 1.5
>>>> stream
>>> and
>>>> run through my litany of projects to see if everything looks sane.
>>> Unless
>>>> anything dramatic comes up in the next couple days, I think we
>>>> should
>>> call
>>>> it a release. Hopefully we can avoid pushing this back any more...
>> :-)
>>>>
>>>> Daniel
>>>>
>>>> On Tue, Apr 20, 2010 at 7:15 PM, Antoine Toulme <
>> antoine@lunar-ocean.com
>>>>> wrote:
>>>>
>>>>> The release script will fail if I try to release with failing
>>>>> specs.
>>> The
>>>>> alternative is to comment them as pending.
>>>>> I can try to tackle them very quickly - but my Scala book is
>>>>> supposed
>>> to
>>>>> arrive tomorrow.
>>>>>
>>>>>
>>>>> On Tue, Apr 20, 2010 at 17:06, Daniel Spiewak
>>>>> <dj...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> We can either issue RC2, or we can go straight to the full
>>>>>> release.
>>> My
>>>>>> impression is that JRuby 1.5 isn't going to go GA for a while, so
>> it's
>>>> not
>>>>>> worth waiting unless there's a testing advantage (like fixing
>>>>>> those
>>>> specs I
>>>>>> don't understand). :-)
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <
>>>> antoine@lunar-ocean.com>wrote:
>>>>>>
>>>>>>> I'm all for it. Want to issue RC2 ? I can try again, with
>>>>>>> pygments
>>> this
>>>>>>> time.
>>>>>>>
>>>>>>> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <djspiewak@gmail.com
>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Default versions for ScalaCheck and ScalaTest pushed to 1.6 and
>>>> 1.0.1,
>>>>>>>> respectively (Bill just made the release). Three tests are
>> failing
>>>> in
>>>>>>> the
>>>>>>>> ScalaTest specs, but I'm not sufficiently familiar with
>>>>>>>> ScalaTest
>>> as
>>>> to
>>>>>>>> figure out what's going on (one of them just looks like a
>> transient
>>>> FSC
>>>>>>>> failure).
>>>>>>>>
>>>>>>>> Once we get these passing again (and assuming it's before
>> Tuesday),
>>> I
>>>>>>> vote
>>>>>>>> that we cut a new release candidate so we can get some more
>> testing
>>>> in
>>>>>>>> before our deadline for JRuby 1.5.
>>>>>>>>
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>> On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <
>>>>>>> alex.boisvert@gmail.com
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <
>>>> djspiewak@gmail.com
>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I thought about that, but I'm leery about holding up our
>>> release
>>>>>>> even
>>>>>>>>>> longer. I wouldn't mind giving them one or two days, but any
>>>>>>> longer...
>>>>>>>>>>
>>>>>>>>>> How about this: we allow maybe two days waiting for JRuby
>> 1.5.
>>>> In
>>>>>>> the
>>>>>>>>>> meantime, we test with the 1.5 RC to make sure there isn't
>>>> anything
>>>>>>>> that
>>>>>>>>>> would trip us up. If 1.5 GA doesn't come out before Tuesday
>>>> night,
>>>>>>> we
>>>>>>>> do
>>>>>>>>>> the 1.4 release without it. Once 1.5 comes out, we can test
>>>>>>> against it
>>>>>>>>> and
>>>>>>>>>> repackage the all-in-one distribution. If there are any bugs
>>>> which
>>>>>>>> crop
>>>>>>>>> up
>>>>>>>>>> because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1
>> (or
>>>>>>> perhaps
>>>>>>>>>> 1.4.0.1) release at that time. I don't see this as a
>>>> particularly
>>>>>>>> likely
>>>>>>>>>> scenario though, it seems like all we should need to do is
>>>>>>> repackage
>>>>>>>> the
>>>>>>>>>> all-in-one and we'll be golden.
>>>>>>>>>>
>>>>>>>>>> How does that strike everyone?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fine by me.
>>>>>>>>>
>>>>>>>>> alex
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Daniel, on this, here is a tidbit of wisdom from Assaf:
In ~/.ssh/config, add:
Host people.apache.org
User <your apache user name>
On Wed, Apr 21, 2010 at 21:00, Daniel Spiewak <dj...@gmail.com> wrote:
> You better do it. I am not privy to the words of power required to cut a
> release. That and my Apache username is different from my local username,
> so the release task doesn't work for me. :-)
>
> Daniel
>
> On Wed, Apr 21, 2010 at 10:51 PM, Antoine Toulme <antoine@lunar-ocean.com
> >wrote:
>
> > I'll try to cut RC2 now, unless you're on it ?
> >
> > Thanks Daniel!
> >
> > On Wed, Apr 21, 2010 at 19:46, Daniel Spiewak <dj...@gmail.com>
> wrote:
> >
> > > The issues with the specs were caused by flaky FSC. I've rejiggered
> the
> > > Rake task to turn off FSC when running the spec suite (for Buildr).
> All
> > > the
> > > specs are passing now, so we can go ahead and cut RC2.
> > >
> > > In the meantime, I'm going to grab the latest from the JRuby 1.5 stream
> > and
> > > run through my litany of projects to see if everything looks sane.
> > Unless
> > > anything dramatic comes up in the next couple days, I think we should
> > call
> > > it a release. Hopefully we can avoid pushing this back any more...
> :-)
> > >
> > > Daniel
> > >
> > > On Tue, Apr 20, 2010 at 7:15 PM, Antoine Toulme <
> antoine@lunar-ocean.com
> > > >wrote:
> > >
> > > > The release script will fail if I try to release with failing specs.
> > The
> > > > alternative is to comment them as pending.
> > > > I can try to tackle them very quickly - but my Scala book is supposed
> > to
> > > > arrive tomorrow.
> > > >
> > > >
> > > > On Tue, Apr 20, 2010 at 17:06, Daniel Spiewak <dj...@gmail.com>
> > > wrote:
> > > >
> > > >> We can either issue RC2, or we can go straight to the full release.
> > My
> > > >> impression is that JRuby 1.5 isn't going to go GA for a while, so
> it's
> > > not
> > > >> worth waiting unless there's a testing advantage (like fixing those
> > > specs I
> > > >> don't understand). :-)
> > > >>
> > > >> Daniel
> > > >>
> > > >>
> > > >> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <
> > > antoine@lunar-ocean.com>wrote:
> > > >>
> > > >>> I'm all for it. Want to issue RC2 ? I can try again, with pygments
> > this
> > > >>> time.
> > > >>>
> > > >>> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <djspiewak@gmail.com
> >
> > > >>> wrote:
> > > >>>
> > > >>> > Default versions for ScalaCheck and ScalaTest pushed to 1.6 and
> > > 1.0.1,
> > > >>> > respectively (Bill just made the release). Three tests are
> failing
> > > in
> > > >>> the
> > > >>> > ScalaTest specs, but I'm not sufficiently familiar with ScalaTest
> > as
> > > to
> > > >>> > figure out what's going on (one of them just looks like a
> transient
> > > FSC
> > > >>> > failure).
> > > >>> >
> > > >>> > Once we get these passing again (and assuming it's before
> Tuesday),
> > I
> > > >>> vote
> > > >>> > that we cut a new release candidate so we can get some more
> testing
> > > in
> > > >>> > before our deadline for JRuby 1.5.
> > > >>> >
> > > >>> > Daniel
> > > >>> >
> > > >>> > On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <
> > > >>> alex.boisvert@gmail.com
> > > >>> > >wrote:
> > > >>> >
> > > >>> > > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <
> > > djspiewak@gmail.com
> > > >>> >
> > > >>> > > wrote:
> > > >>> > >
> > > >>> > > >
> > > >>> > > > I thought about that, but I'm leery about holding up our
> > release
> > > >>> even
> > > >>> > > > longer. I wouldn't mind giving them one or two days, but any
> > > >>> longer...
> > > >>> > > >
> > > >>> > > > How about this: we allow maybe two days waiting for JRuby
> 1.5.
> > > In
> > > >>> the
> > > >>> > > > meantime, we test with the 1.5 RC to make sure there isn't
> > > anything
> > > >>> > that
> > > >>> > > > would trip us up. If 1.5 GA doesn't come out before Tuesday
> > > night,
> > > >>> we
> > > >>> > do
> > > >>> > > > the 1.4 release without it. Once 1.5 comes out, we can test
> > > >>> against it
> > > >>> > > and
> > > >>> > > > repackage the all-in-one distribution. If there are any bugs
> > > which
> > > >>> > crop
> > > >>> > > up
> > > >>> > > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1
> (or
> > > >>> perhaps
> > > >>> > > > 1.4.0.1) release at that time. I don't see this as a
> > > particularly
> > > >>> > likely
> > > >>> > > > scenario though, it seems like all we should need to do is
> > > >>> repackage
> > > >>> > the
> > > >>> > > > all-in-one and we'll be golden.
> > > >>> > > >
> > > >>> > > > How does that strike everyone?
> > > >>> > > >
> > > >>> > >
> > > >>> > > Fine by me.
> > > >>> > >
> > > >>> > > alex
> > > >>> > >
> > > >>> >
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
You better do it. I am not privy to the words of power required to cut a
release. That and my Apache username is different from my local username,
so the release task doesn't work for me. :-)
Daniel
On Wed, Apr 21, 2010 at 10:51 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> I'll try to cut RC2 now, unless you're on it ?
>
> Thanks Daniel!
>
> On Wed, Apr 21, 2010 at 19:46, Daniel Spiewak <dj...@gmail.com> wrote:
>
> > The issues with the specs were caused by flaky FSC. I've rejiggered the
> > Rake task to turn off FSC when running the spec suite (for Buildr). All
> > the
> > specs are passing now, so we can go ahead and cut RC2.
> >
> > In the meantime, I'm going to grab the latest from the JRuby 1.5 stream
> and
> > run through my litany of projects to see if everything looks sane.
> Unless
> > anything dramatic comes up in the next couple days, I think we should
> call
> > it a release. Hopefully we can avoid pushing this back any more... :-)
> >
> > Daniel
> >
> > On Tue, Apr 20, 2010 at 7:15 PM, Antoine Toulme <antoine@lunar-ocean.com
> > >wrote:
> >
> > > The release script will fail if I try to release with failing specs.
> The
> > > alternative is to comment them as pending.
> > > I can try to tackle them very quickly - but my Scala book is supposed
> to
> > > arrive tomorrow.
> > >
> > >
> > > On Tue, Apr 20, 2010 at 17:06, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> > >
> > >> We can either issue RC2, or we can go straight to the full release.
> My
> > >> impression is that JRuby 1.5 isn't going to go GA for a while, so it's
> > not
> > >> worth waiting unless there's a testing advantage (like fixing those
> > specs I
> > >> don't understand). :-)
> > >>
> > >> Daniel
> > >>
> > >>
> > >> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <
> > antoine@lunar-ocean.com>wrote:
> > >>
> > >>> I'm all for it. Want to issue RC2 ? I can try again, with pygments
> this
> > >>> time.
> > >>>
> > >>> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <dj...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > Default versions for ScalaCheck and ScalaTest pushed to 1.6 and
> > 1.0.1,
> > >>> > respectively (Bill just made the release). Three tests are failing
> > in
> > >>> the
> > >>> > ScalaTest specs, but I'm not sufficiently familiar with ScalaTest
> as
> > to
> > >>> > figure out what's going on (one of them just looks like a transient
> > FSC
> > >>> > failure).
> > >>> >
> > >>> > Once we get these passing again (and assuming it's before Tuesday),
> I
> > >>> vote
> > >>> > that we cut a new release candidate so we can get some more testing
> > in
> > >>> > before our deadline for JRuby 1.5.
> > >>> >
> > >>> > Daniel
> > >>> >
> > >>> > On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <
> > >>> alex.boisvert@gmail.com
> > >>> > >wrote:
> > >>> >
> > >>> > > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <
> > djspiewak@gmail.com
> > >>> >
> > >>> > > wrote:
> > >>> > >
> > >>> > > >
> > >>> > > > I thought about that, but I'm leery about holding up our
> release
> > >>> even
> > >>> > > > longer. I wouldn't mind giving them one or two days, but any
> > >>> longer...
> > >>> > > >
> > >>> > > > How about this: we allow maybe two days waiting for JRuby 1.5.
> > In
> > >>> the
> > >>> > > > meantime, we test with the 1.5 RC to make sure there isn't
> > anything
> > >>> > that
> > >>> > > > would trip us up. If 1.5 GA doesn't come out before Tuesday
> > night,
> > >>> we
> > >>> > do
> > >>> > > > the 1.4 release without it. Once 1.5 comes out, we can test
> > >>> against it
> > >>> > > and
> > >>> > > > repackage the all-in-one distribution. If there are any bugs
> > which
> > >>> > crop
> > >>> > > up
> > >>> > > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or
> > >>> perhaps
> > >>> > > > 1.4.0.1) release at that time. I don't see this as a
> > particularly
> > >>> > likely
> > >>> > > > scenario though, it seems like all we should need to do is
> > >>> repackage
> > >>> > the
> > >>> > > > all-in-one and we'll be golden.
> > >>> > > >
> > >>> > > > How does that strike everyone?
> > >>> > > >
> > >>> > >
> > >>> > > Fine by me.
> > >>> > >
> > >>> > > alex
> > >>> > >
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I'll try to cut RC2 now, unless you're on it ?
Thanks Daniel!
On Wed, Apr 21, 2010 at 19:46, Daniel Spiewak <dj...@gmail.com> wrote:
> The issues with the specs were caused by flaky FSC. I've rejiggered the
> Rake task to turn off FSC when running the spec suite (for Buildr). All
> the
> specs are passing now, so we can go ahead and cut RC2.
>
> In the meantime, I'm going to grab the latest from the JRuby 1.5 stream and
> run through my litany of projects to see if everything looks sane. Unless
> anything dramatic comes up in the next couple days, I think we should call
> it a release. Hopefully we can avoid pushing this back any more... :-)
>
> Daniel
>
> On Tue, Apr 20, 2010 at 7:15 PM, Antoine Toulme <antoine@lunar-ocean.com
> >wrote:
>
> > The release script will fail if I try to release with failing specs. The
> > alternative is to comment them as pending.
> > I can try to tackle them very quickly - but my Scala book is supposed to
> > arrive tomorrow.
> >
> >
> > On Tue, Apr 20, 2010 at 17:06, Daniel Spiewak <dj...@gmail.com>
> wrote:
> >
> >> We can either issue RC2, or we can go straight to the full release. My
> >> impression is that JRuby 1.5 isn't going to go GA for a while, so it's
> not
> >> worth waiting unless there's a testing advantage (like fixing those
> specs I
> >> don't understand). :-)
> >>
> >> Daniel
> >>
> >>
> >> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <
> antoine@lunar-ocean.com>wrote:
> >>
> >>> I'm all for it. Want to issue RC2 ? I can try again, with pygments this
> >>> time.
> >>>
> >>> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <dj...@gmail.com>
> >>> wrote:
> >>>
> >>> > Default versions for ScalaCheck and ScalaTest pushed to 1.6 and
> 1.0.1,
> >>> > respectively (Bill just made the release). Three tests are failing
> in
> >>> the
> >>> > ScalaTest specs, but I'm not sufficiently familiar with ScalaTest as
> to
> >>> > figure out what's going on (one of them just looks like a transient
> FSC
> >>> > failure).
> >>> >
> >>> > Once we get these passing again (and assuming it's before Tuesday), I
> >>> vote
> >>> > that we cut a new release candidate so we can get some more testing
> in
> >>> > before our deadline for JRuby 1.5.
> >>> >
> >>> > Daniel
> >>> >
> >>> > On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <
> >>> alex.boisvert@gmail.com
> >>> > >wrote:
> >>> >
> >>> > > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <
> djspiewak@gmail.com
> >>> >
> >>> > > wrote:
> >>> > >
> >>> > > >
> >>> > > > I thought about that, but I'm leery about holding up our release
> >>> even
> >>> > > > longer. I wouldn't mind giving them one or two days, but any
> >>> longer...
> >>> > > >
> >>> > > > How about this: we allow maybe two days waiting for JRuby 1.5.
> In
> >>> the
> >>> > > > meantime, we test with the 1.5 RC to make sure there isn't
> anything
> >>> > that
> >>> > > > would trip us up. If 1.5 GA doesn't come out before Tuesday
> night,
> >>> we
> >>> > do
> >>> > > > the 1.4 release without it. Once 1.5 comes out, we can test
> >>> against it
> >>> > > and
> >>> > > > repackage the all-in-one distribution. If there are any bugs
> which
> >>> > crop
> >>> > > up
> >>> > > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or
> >>> perhaps
> >>> > > > 1.4.0.1) release at that time. I don't see this as a
> particularly
> >>> > likely
> >>> > > > scenario though, it seems like all we should need to do is
> >>> repackage
> >>> > the
> >>> > > > all-in-one and we'll be golden.
> >>> > > >
> >>> > > > How does that strike everyone?
> >>> > > >
> >>> > >
> >>> > > Fine by me.
> >>> > >
> >>> > > alex
> >>> > >
> >>> >
> >>>
> >>
> >>
> >
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
The issues with the specs were caused by flaky FSC. I've rejiggered the
Rake task to turn off FSC when running the spec suite (for Buildr). All the
specs are passing now, so we can go ahead and cut RC2.
In the meantime, I'm going to grab the latest from the JRuby 1.5 stream and
run through my litany of projects to see if everything looks sane. Unless
anything dramatic comes up in the next couple days, I think we should call
it a release. Hopefully we can avoid pushing this back any more... :-)
Daniel
On Tue, Apr 20, 2010 at 7:15 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> The release script will fail if I try to release with failing specs. The
> alternative is to comment them as pending.
> I can try to tackle them very quickly - but my Scala book is supposed to
> arrive tomorrow.
>
>
> On Tue, Apr 20, 2010 at 17:06, Daniel Spiewak <dj...@gmail.com> wrote:
>
>> We can either issue RC2, or we can go straight to the full release. My
>> impression is that JRuby 1.5 isn't going to go GA for a while, so it's not
>> worth waiting unless there's a testing advantage (like fixing those specs I
>> don't understand). :-)
>>
>> Daniel
>>
>>
>> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>>
>>> I'm all for it. Want to issue RC2 ? I can try again, with pygments this
>>> time.
>>>
>>> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <dj...@gmail.com>
>>> wrote:
>>>
>>> > Default versions for ScalaCheck and ScalaTest pushed to 1.6 and 1.0.1,
>>> > respectively (Bill just made the release). Three tests are failing in
>>> the
>>> > ScalaTest specs, but I'm not sufficiently familiar with ScalaTest as to
>>> > figure out what's going on (one of them just looks like a transient FSC
>>> > failure).
>>> >
>>> > Once we get these passing again (and assuming it's before Tuesday), I
>>> vote
>>> > that we cut a new release candidate so we can get some more testing in
>>> > before our deadline for JRuby 1.5.
>>> >
>>> > Daniel
>>> >
>>> > On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <
>>> alex.boisvert@gmail.com
>>> > >wrote:
>>> >
>>> > > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <djspiewak@gmail.com
>>> >
>>> > > wrote:
>>> > >
>>> > > >
>>> > > > I thought about that, but I'm leery about holding up our release
>>> even
>>> > > > longer. I wouldn't mind giving them one or two days, but any
>>> longer...
>>> > > >
>>> > > > How about this: we allow maybe two days waiting for JRuby 1.5. In
>>> the
>>> > > > meantime, we test with the 1.5 RC to make sure there isn't anything
>>> > that
>>> > > > would trip us up. If 1.5 GA doesn't come out before Tuesday night,
>>> we
>>> > do
>>> > > > the 1.4 release without it. Once 1.5 comes out, we can test
>>> against it
>>> > > and
>>> > > > repackage the all-in-one distribution. If there are any bugs which
>>> > crop
>>> > > up
>>> > > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or
>>> perhaps
>>> > > > 1.4.0.1) release at that time. I don't see this as a particularly
>>> > likely
>>> > > > scenario though, it seems like all we should need to do is
>>> repackage
>>> > the
>>> > > > all-in-one and we'll be golden.
>>> > > >
>>> > > > How does that strike everyone?
>>> > > >
>>> > >
>>> > > Fine by me.
>>> > >
>>> > > alex
>>> > >
>>> >
>>>
>>
>>
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
The release script will fail if I try to release with failing specs. The
alternative is to comment them as pending.
I can try to tackle them very quickly - but my Scala book is supposed to
arrive tomorrow.
On Tue, Apr 20, 2010 at 17:06, Daniel Spiewak <dj...@gmail.com> wrote:
> We can either issue RC2, or we can go straight to the full release. My
> impression is that JRuby 1.5 isn't going to go GA for a while, so it's not
> worth waiting unless there's a testing advantage (like fixing those specs I
> don't understand). :-)
>
> Daniel
>
>
> On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>> I'm all for it. Want to issue RC2 ? I can try again, with pygments this
>> time.
>>
>> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <dj...@gmail.com>
>> wrote:
>>
>> > Default versions for ScalaCheck and ScalaTest pushed to 1.6 and 1.0.1,
>> > respectively (Bill just made the release). Three tests are failing in
>> the
>> > ScalaTest specs, but I'm not sufficiently familiar with ScalaTest as to
>> > figure out what's going on (one of them just looks like a transient FSC
>> > failure).
>> >
>> > Once we get these passing again (and assuming it's before Tuesday), I
>> vote
>> > that we cut a new release candidate so we can get some more testing in
>> > before our deadline for JRuby 1.5.
>> >
>> > Daniel
>> >
>> > On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <
>> alex.boisvert@gmail.com
>> > >wrote:
>> >
>> > > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <dj...@gmail.com>
>> > > wrote:
>> > >
>> > > >
>> > > > I thought about that, but I'm leery about holding up our release
>> even
>> > > > longer. I wouldn't mind giving them one or two days, but any
>> longer...
>> > > >
>> > > > How about this: we allow maybe two days waiting for JRuby 1.5. In
>> the
>> > > > meantime, we test with the 1.5 RC to make sure there isn't anything
>> > that
>> > > > would trip us up. If 1.5 GA doesn't come out before Tuesday night,
>> we
>> > do
>> > > > the 1.4 release without it. Once 1.5 comes out, we can test against
>> it
>> > > and
>> > > > repackage the all-in-one distribution. If there are any bugs which
>> > crop
>> > > up
>> > > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or
>> perhaps
>> > > > 1.4.0.1) release at that time. I don't see this as a particularly
>> > likely
>> > > > scenario though, it seems like all we should need to do is repackage
>> > the
>> > > > all-in-one and we'll be golden.
>> > > >
>> > > > How does that strike everyone?
>> > > >
>> > >
>> > > Fine by me.
>> > >
>> > > alex
>> > >
>> >
>>
>
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
We can either issue RC2, or we can go straight to the full release. My
impression is that JRuby 1.5 isn't going to go GA for a while, so it's not
worth waiting unless there's a testing advantage (like fixing those specs I
don't understand). :-)
Daniel
On Tue, Apr 20, 2010 at 7:04 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> I'm all for it. Want to issue RC2 ? I can try again, with pygments this
> time.
>
> On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <dj...@gmail.com> wrote:
>
> > Default versions for ScalaCheck and ScalaTest pushed to 1.6 and 1.0.1,
> > respectively (Bill just made the release). Three tests are failing in
> the
> > ScalaTest specs, but I'm not sufficiently familiar with ScalaTest as to
> > figure out what's going on (one of them just looks like a transient FSC
> > failure).
> >
> > Once we get these passing again (and assuming it's before Tuesday), I
> vote
> > that we cut a new release candidate so we can get some more testing in
> > before our deadline for JRuby 1.5.
> >
> > Daniel
> >
> > On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <alex.boisvert@gmail.com
> > >wrote:
> >
> > > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <dj...@gmail.com>
> > > wrote:
> > >
> > > >
> > > > I thought about that, but I'm leery about holding up our release even
> > > > longer. I wouldn't mind giving them one or two days, but any
> longer...
> > > >
> > > > How about this: we allow maybe two days waiting for JRuby 1.5. In
> the
> > > > meantime, we test with the 1.5 RC to make sure there isn't anything
> > that
> > > > would trip us up. If 1.5 GA doesn't come out before Tuesday night,
> we
> > do
> > > > the 1.4 release without it. Once 1.5 comes out, we can test against
> it
> > > and
> > > > repackage the all-in-one distribution. If there are any bugs which
> > crop
> > > up
> > > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or
> perhaps
> > > > 1.4.0.1) release at that time. I don't see this as a particularly
> > likely
> > > > scenario though, it seems like all we should need to do is repackage
> > the
> > > > all-in-one and we'll be golden.
> > > >
> > > > How does that strike everyone?
> > > >
> > >
> > > Fine by me.
> > >
> > > alex
> > >
> >
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I'm all for it. Want to issue RC2 ? I can try again, with pygments this
time.
On Sun, Apr 18, 2010 at 22:47, Daniel Spiewak <dj...@gmail.com> wrote:
> Default versions for ScalaCheck and ScalaTest pushed to 1.6 and 1.0.1,
> respectively (Bill just made the release). Three tests are failing in the
> ScalaTest specs, but I'm not sufficiently familiar with ScalaTest as to
> figure out what's going on (one of them just looks like a transient FSC
> failure).
>
> Once we get these passing again (and assuming it's before Tuesday), I vote
> that we cut a new release candidate so we can get some more testing in
> before our deadline for JRuby 1.5.
>
> Daniel
>
> On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <alex.boisvert@gmail.com
> >wrote:
>
> > On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> >
> > >
> > > I thought about that, but I'm leery about holding up our release even
> > > longer. I wouldn't mind giving them one or two days, but any longer...
> > >
> > > How about this: we allow maybe two days waiting for JRuby 1.5. In the
> > > meantime, we test with the 1.5 RC to make sure there isn't anything
> that
> > > would trip us up. If 1.5 GA doesn't come out before Tuesday night, we
> do
> > > the 1.4 release without it. Once 1.5 comes out, we can test against it
> > and
> > > repackage the all-in-one distribution. If there are any bugs which
> crop
> > up
> > > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or perhaps
> > > 1.4.0.1) release at that time. I don't see this as a particularly
> likely
> > > scenario though, it seems like all we should need to do is repackage
> the
> > > all-in-one and we'll be golden.
> > >
> > > How does that strike everyone?
> > >
> >
> > Fine by me.
> >
> > alex
> >
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
Default versions for ScalaCheck and ScalaTest pushed to 1.6 and 1.0.1,
respectively (Bill just made the release). Three tests are failing in the
ScalaTest specs, but I'm not sufficiently familiar with ScalaTest as to
figure out what's going on (one of them just looks like a transient FSC
failure).
Once we get these passing again (and assuming it's before Tuesday), I vote
that we cut a new release candidate so we can get some more testing in
before our deadline for JRuby 1.5.
Daniel
On Sun, Apr 18, 2010 at 11:10 PM, Alex Boisvert <al...@gmail.com>wrote:
> On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> >
> > I thought about that, but I'm leery about holding up our release even
> > longer. I wouldn't mind giving them one or two days, but any longer...
> >
> > How about this: we allow maybe two days waiting for JRuby 1.5. In the
> > meantime, we test with the 1.5 RC to make sure there isn't anything that
> > would trip us up. If 1.5 GA doesn't come out before Tuesday night, we do
> > the 1.4 release without it. Once 1.5 comes out, we can test against it
> and
> > repackage the all-in-one distribution. If there are any bugs which crop
> up
> > because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or perhaps
> > 1.4.0.1) release at that time. I don't see this as a particularly likely
> > scenario though, it seems like all we should need to do is repackage the
> > all-in-one and we'll be golden.
> >
> > How does that strike everyone?
> >
>
> Fine by me.
>
> alex
>
Re: Buildr 1.4.0 RC1
Posted by Alex Boisvert <al...@gmail.com>.
On Sun, Apr 18, 2010 at 8:44 PM, Daniel Spiewak <dj...@gmail.com> wrote:
>
> I thought about that, but I'm leery about holding up our release even
> longer. I wouldn't mind giving them one or two days, but any longer...
>
> How about this: we allow maybe two days waiting for JRuby 1.5. In the
> meantime, we test with the 1.5 RC to make sure there isn't anything that
> would trip us up. If 1.5 GA doesn't come out before Tuesday night, we do
> the 1.4 release without it. Once 1.5 comes out, we can test against it and
> repackage the all-in-one distribution. If there are any bugs which crop up
> because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or perhaps
> 1.4.0.1) release at that time. I don't see this as a particularly likely
> scenario though, it seems like all we should need to do is repackage the
> all-in-one and we'll be golden.
>
> How does that strike everyone?
>
Fine by me.
alex
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
> I'm fine with a release if ScalaTest 1.1 isn't released in a couple days.
> Bill did release 1.1-SNAPSHOT as response to my request so I think it it's
> just a matter of days.
>
Just heard back from him. He's planning to do a release tonight so that we
can move forward.
> JRuby 1.5 RC1 was released this week and it would be nice to wait + test
> with the final release before we release.
>
I thought about that, but I'm leery about holding up our release even
longer. I wouldn't mind giving them one or two days, but any longer...
How about this: we allow maybe two days waiting for JRuby 1.5. In the
meantime, we test with the 1.5 RC to make sure there isn't anything that
would trip us up. If 1.5 GA doesn't come out before Tuesday night, we do
the 1.4 release without it. Once 1.5 comes out, we can test against it and
repackage the all-in-one distribution. If there are any bugs which crop up
because of changes from 1.5 RC to 1.5 GA, we can do a 1.4.1 (or perhaps
1.4.0.1) release at that time. I don't see this as a particularly likely
scenario though, it seems like all we should need to do is repackage the
all-in-one and we'll be golden.
How does that strike everyone?
Daniel
Re: Buildr 1.4.0 RC1
Posted by Alex Boisvert <al...@gmail.com>.
I'm fine with a release if ScalaTest 1.1 isn't released in a couple days.
Bill did release 1.1-SNAPSHOT as response to my request so I think it it's
just a matter of days.
JRuby 1.5 RC1 was released this week and it would be nice to wait + test
with the final release before we release.
alex
On Sun, Apr 18, 2010 at 5:24 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> > I think Alex could try to give him a nudge. And if that doesn't work, we
> > should go with Daniel's idea.
> >
>
> Nudge sent. I'll pass the word along as soon as Bill gets back to me.
>
> If we don't hear from him in a couple days, I vote we move forward without
> waiting for the release.
>
> Daniel
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
> I think Alex could try to give him a nudge. And if that doesn't work, we
> should go with Daniel's idea.
>
Nudge sent. I'll pass the word along as soon as Bill gets back to me.
If we don't hear from him in a couple days, I vote we move forward without
waiting for the release.
Daniel
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
On the thread, Bill said he would do the release last week.
I think Alex could try to give him a nudge. And if that doesn't work, we
should go with Daniel's idea.
OK with that ?
Antoine
On Sat, Apr 17, 2010 at 22:29, Daniel Spiewak <dj...@gmail.com> wrote:
> My vote: push the default ScalaCheck version forward to 1.6. This is
> compatible with Specs 1.6.2 and Scala 2.7.7, the latest versions of each.
> We would of course have to add a note to the documentation in the ScalaTest
> section mentioning that ScalaCheck support requires the explicit use of
> Buildr.version['scala.check'] = '1.5'.
>
> The only other option is to leave things as they stand, which is to keep
> ScalaCheck compatible with ScalaTest by default and add the note to the
> Specs section. The only difference is that ScalaTest 1.0 is not
> *officially
> * compatible with Scala 2.7.7 (nor is ScalaCheck 1.5, for that matter), so
> we would be deliberately choosing to hobble Specs for the sake of a library
> which simply hasn't kept up with the release cycles. If that is the
> consensus then I'm ok with it, but we should be conscious of the fact that
> we are actively choosing one "default supported" version over another, and
> (if we choose to leave things as they are) that version also implies an old
> version of Scala itself (2.7.4).
>
> In either case, a little more documentation is required, detailing what a
> user would have to do to use ScalaCheck with either ScalaTest or Specs
> (whichever becomes the unsupported option).
>
> Daniel
>
> On Sat, Apr 17, 2010 at 10:57 PM, Antoine Toulme <antoine@lunar-ocean.com
> >wrote:
>
> > Ok so I guess our release is blocked by that item.
> >
> > That's the last critical bug we have I think.
> >
> > I propose that we release as soon as we have that in check. Thoughts ?
> >
> > On Sun, Apr 11, 2010 at 14:53, Alex Boisvert <alex.boisvert@gmail.com
> > >wrote:
> >
> > > On Sat, Apr 10, 2010 at 11:28 AM, Antoine Toulme <
> > antoine@lunar-ocean.com>wrote:
> > >
> > >> We're down to 5 open issues.
> > >>
> > >>
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310734&fixfor=12313152&resolution=-1&sorter/field=priority&sorter/order=DESC
> > >>
> > >
> > > BTW, I've reported the issue about ScalaTest + Specs/ScalaCheck here:
> > >
> > >
> >
> http://groups.google.com/group/scalatest-users/browse_thread/thread/a429b4adf551278d#
> > > and waiting for an updated release of ScalaTest.
> > >
> > > (I can't comment on Jira right now since it was hacked earlier this
> week;
> > > waiting for my account to be reenabled).
> > >
> > > alex
> > >
> > >
> >
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
My vote: push the default ScalaCheck version forward to 1.6. This is
compatible with Specs 1.6.2 and Scala 2.7.7, the latest versions of each.
We would of course have to add a note to the documentation in the ScalaTest
section mentioning that ScalaCheck support requires the explicit use of
Buildr.version['scala.check'] = '1.5'.
The only other option is to leave things as they stand, which is to keep
ScalaCheck compatible with ScalaTest by default and add the note to the
Specs section. The only difference is that ScalaTest 1.0 is not *officially
* compatible with Scala 2.7.7 (nor is ScalaCheck 1.5, for that matter), so
we would be deliberately choosing to hobble Specs for the sake of a library
which simply hasn't kept up with the release cycles. If that is the
consensus then I'm ok with it, but we should be conscious of the fact that
we are actively choosing one "default supported" version over another, and
(if we choose to leave things as they are) that version also implies an old
version of Scala itself (2.7.4).
In either case, a little more documentation is required, detailing what a
user would have to do to use ScalaCheck with either ScalaTest or Specs
(whichever becomes the unsupported option).
Daniel
On Sat, Apr 17, 2010 at 10:57 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> Ok so I guess our release is blocked by that item.
>
> That's the last critical bug we have I think.
>
> I propose that we release as soon as we have that in check. Thoughts ?
>
> On Sun, Apr 11, 2010 at 14:53, Alex Boisvert <alex.boisvert@gmail.com
> >wrote:
>
> > On Sat, Apr 10, 2010 at 11:28 AM, Antoine Toulme <
> antoine@lunar-ocean.com>wrote:
> >
> >> We're down to 5 open issues.
> >>
> >>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310734&fixfor=12313152&resolution=-1&sorter/field=priority&sorter/order=DESC
> >>
> >
> > BTW, I've reported the issue about ScalaTest + Specs/ScalaCheck here:
> >
> >
> http://groups.google.com/group/scalatest-users/browse_thread/thread/a429b4adf551278d#
> > and waiting for an updated release of ScalaTest.
> >
> > (I can't comment on Jira right now since it was hacked earlier this week;
> > waiting for my account to be reenabled).
> >
> > alex
> >
> >
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Ok so I guess our release is blocked by that item.
That's the last critical bug we have I think.
I propose that we release as soon as we have that in check. Thoughts ?
On Sun, Apr 11, 2010 at 14:53, Alex Boisvert <al...@gmail.com>wrote:
> On Sat, Apr 10, 2010 at 11:28 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>> We're down to 5 open issues.
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310734&fixfor=12313152&resolution=-1&sorter/field=priority&sorter/order=DESC
>>
>
> BTW, I've reported the issue about ScalaTest + Specs/ScalaCheck here:
>
> http://groups.google.com/group/scalatest-users/browse_thread/thread/a429b4adf551278d#
> and waiting for an updated release of ScalaTest.
>
> (I can't comment on Jira right now since it was hacked earlier this week;
> waiting for my account to be reenabled).
>
> alex
>
>
Re: Buildr 1.4.0 RC1
Posted by Alex Boisvert <al...@gmail.com>.
On Sat, Apr 10, 2010 at 11:28 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> We're down to 5 open issues.
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310734&fixfor=12313152&resolution=-1&sorter/field=priority&sorter/order=DESC
>
BTW, I've reported the issue about ScalaTest + Specs/ScalaCheck here:
http://groups.google.com/group/scalatest-users/browse_thread/thread/a429b4adf551278d#
and waiting for an updated release of ScalaTest.
(I can't comment on Jira right now since it was hacked earlier this week;
waiting for my account to be reenabled).
alex
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
We're down to 5 open issues.
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310734&fixfor=12313152&resolution=-1&sorter/field=priority&sorter/order=DESC
Specs are failing. I count 18 failures on my machine.
I fixed a few bugs this morning and now have to do my taxes...
I recommend we defer or fix the last bugs we have, and work only on making
all specs work. Let's release by end of next week!
On Sun, Apr 4, 2010 at 21:40, Alex Boisvert <al...@gmail.com> wrote:
> I'll give a good shot at the 3 assigned to me this week. If there's no
> immediate takers for the unassigned ones, I think we should mark them for
> 1.4.1. I would not want to push 1.4.0 further out.
>
> alex
>
>
>
> On Sun, Apr 4, 2010 at 8:25 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>> We're down to 11 open issues. I also gave Daniel a patch that hopefully
>> will help with CC.
>>
>> On Sat, Apr 3, 2010 at 11:54, Alex Boisvert <al...@gmail.com>wrote:
>>
>>> Cool, thanks for taking care of the RC. I'll look at the remaining 1.4
>>> issues later.
>>>
>>> alex
>>>
>>>
>>> On Fri, Apr 2, 2010 at 6:41 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>>>
>>>> I trimmed down the issues for 1.4 to 17. 6 of them are assigned to me
>>>> and
>>>> I'll do my best to tackle them ASAP.
>>>>
>>>> Thanks,
>>>>
>>>> Antoine
>>>>
>>>> On Thu, Apr 1, 2010 at 12:54, Antoine Toulme <antoine@lunar-ocean.com
>>>> >wrote:
>>>>
>>>> > I'll look at the bugs on the 1.4 roadmap tonight and will filter those
>>>> to
>>>> > be fixed in subsequent releases.
>>>> >
>>>> > Here is the filter I will use:
>>>> >
>>>> >
>>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310734&fixfor=12313152
>>>> >
>>>> > I hope to have a good handle over what needs to be fixed, and I'll
>>>> take a
>>>> > reasonable minimalist approach. If you want your bug to be considered,
>>>> > please push the priority or signal it on it.
>>>> >
>>>> > Thanks!
>>>> >
>>>> > Antoine
>>>> >
>>>> >
>>>> > On Thu, Apr 1, 2010 at 11:54, Daniel Spiewak <dj...@gmail.com>
>>>> wrote:
>>>> >
>>>> >> There is a problem I found (and reported) the other day with our
>>>> default
>>>> >> versions of Specs and ScalaCheck. It can actually cause a compiler
>>>> crash on
>>>> >> some projects, so I think we really need to fix it before we release
>>>> 1.4.0
>>>> >> GA. I don't have the issue number handy right now, but it should be
>>>> the
>>>> >> only open critical issue with the Scala support.
>>>> >>
>>>> >> Daniel
>>>> >>
>>>> >>
>>>> >> On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <
>>>> antoine@lunar-ocean.com>
>>>> >> wrote:
>>>> >>
>>>> >> Hi, the first RC for Buildr 1.4.0 is available here:
>>>> >>>
>>>> >>> http://people.apache.org/~toulmean/buildr/1.4.0<http://people.apache.org/%7Etoulmean/buildr/1.4.0>
>>>> >>>
>>>> >>> Now is the time for testing. In two weeks, we will issue a GA
>>>> release if
>>>> >>> everything is smooth.
>>>> >>>
>>>> >>> Thanks!
>>>> >>>
>>>> >>> Antoine
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>
Re: Buildr 1.4.0 RC1
Posted by Alex Boisvert <al...@gmail.com>.
I'll give a good shot at the 3 assigned to me this week. If there's no
immediate takers for the unassigned ones, I think we should mark them for
1.4.1. I would not want to push 1.4.0 further out.
alex
On Sun, Apr 4, 2010 at 8:25 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> We're down to 11 open issues. I also gave Daniel a patch that hopefully
> will help with CC.
>
> On Sat, Apr 3, 2010 at 11:54, Alex Boisvert <al...@gmail.com>wrote:
>
>> Cool, thanks for taking care of the RC. I'll look at the remaining 1.4
>> issues later.
>>
>> alex
>>
>>
>> On Fri, Apr 2, 2010 at 6:41 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>>
>>> I trimmed down the issues for 1.4 to 17. 6 of them are assigned to me and
>>> I'll do my best to tackle them ASAP.
>>>
>>> Thanks,
>>>
>>> Antoine
>>>
>>> On Thu, Apr 1, 2010 at 12:54, Antoine Toulme <antoine@lunar-ocean.com
>>> >wrote:
>>>
>>> > I'll look at the bugs on the 1.4 roadmap tonight and will filter those
>>> to
>>> > be fixed in subsequent releases.
>>> >
>>> > Here is the filter I will use:
>>> >
>>> >
>>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310734&fixfor=12313152
>>> >
>>> > I hope to have a good handle over what needs to be fixed, and I'll take
>>> a
>>> > reasonable minimalist approach. If you want your bug to be considered,
>>> > please push the priority or signal it on it.
>>> >
>>> > Thanks!
>>> >
>>> > Antoine
>>> >
>>> >
>>> > On Thu, Apr 1, 2010 at 11:54, Daniel Spiewak <dj...@gmail.com>
>>> wrote:
>>> >
>>> >> There is a problem I found (and reported) the other day with our
>>> default
>>> >> versions of Specs and ScalaCheck. It can actually cause a compiler
>>> crash on
>>> >> some projects, so I think we really need to fix it before we release
>>> 1.4.0
>>> >> GA. I don't have the issue number handy right now, but it should be
>>> the
>>> >> only open critical issue with the Scala support.
>>> >>
>>> >> Daniel
>>> >>
>>> >>
>>> >> On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <antoine@lunar-ocean.com
>>> >
>>> >> wrote:
>>> >>
>>> >> Hi, the first RC for Buildr 1.4.0 is available here:
>>> >>>
>>> >>> http://people.apache.org/~toulmean/buildr/1.4.0<http://people.apache.org/%7Etoulmean/buildr/1.4.0>
>>> >>>
>>> >>> Now is the time for testing. In two weeks, we will issue a GA release
>>> if
>>> >>> everything is smooth.
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> Antoine
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
We're down to 11 open issues. I also gave Daniel a patch that hopefully will
help with CC.
On Sat, Apr 3, 2010 at 11:54, Alex Boisvert <al...@gmail.com> wrote:
> Cool, thanks for taking care of the RC. I'll look at the remaining 1.4
> issues later.
>
> alex
>
>
> On Fri, Apr 2, 2010 at 6:41 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
>
>> I trimmed down the issues for 1.4 to 17. 6 of them are assigned to me and
>> I'll do my best to tackle them ASAP.
>>
>> Thanks,
>>
>> Antoine
>>
>> On Thu, Apr 1, 2010 at 12:54, Antoine Toulme <antoine@lunar-ocean.com
>> >wrote:
>>
>> > I'll look at the bugs on the 1.4 roadmap tonight and will filter those
>> to
>> > be fixed in subsequent releases.
>> >
>> > Here is the filter I will use:
>> >
>> >
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310734&fixfor=12313152
>> >
>> > I hope to have a good handle over what needs to be fixed, and I'll take
>> a
>> > reasonable minimalist approach. If you want your bug to be considered,
>> > please push the priority or signal it on it.
>> >
>> > Thanks!
>> >
>> > Antoine
>> >
>> >
>> > On Thu, Apr 1, 2010 at 11:54, Daniel Spiewak <dj...@gmail.com>
>> wrote:
>> >
>> >> There is a problem I found (and reported) the other day with our
>> default
>> >> versions of Specs and ScalaCheck. It can actually cause a compiler
>> crash on
>> >> some projects, so I think we really need to fix it before we release
>> 1.4.0
>> >> GA. I don't have the issue number handy right now, but it should be
>> the
>> >> only open critical issue with the Scala support.
>> >>
>> >> Daniel
>> >>
>> >>
>> >> On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <an...@lunar-ocean.com>
>> >> wrote:
>> >>
>> >> Hi, the first RC for Buildr 1.4.0 is available here:
>> >>>
>> >>> http://people.apache.org/~toulmean/buildr/1.4.0<http://people.apache.org/%7Etoulmean/buildr/1.4.0>
>> >>>
>> >>> Now is the time for testing. In two weeks, we will issue a GA release
>> if
>> >>> everything is smooth.
>> >>>
>> >>> Thanks!
>> >>>
>> >>> Antoine
>> >>>
>> >>
>> >
>>
>
>
Re: Buildr 1.4.0 RC1
Posted by Alex Boisvert <al...@gmail.com>.
Cool, thanks for taking care of the RC. I'll look at the remaining 1.4
issues later.
alex
On Fri, Apr 2, 2010 at 6:41 PM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> I trimmed down the issues for 1.4 to 17. 6 of them are assigned to me and
> I'll do my best to tackle them ASAP.
>
> Thanks,
>
> Antoine
>
> On Thu, Apr 1, 2010 at 12:54, Antoine Toulme <antoine@lunar-ocean.com
> >wrote:
>
> > I'll look at the bugs on the 1.4 roadmap tonight and will filter those to
> > be fixed in subsequent releases.
> >
> > Here is the filter I will use:
> >
> >
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310734&fixfor=12313152
> >
> > I hope to have a good handle over what needs to be fixed, and I'll take a
> > reasonable minimalist approach. If you want your bug to be considered,
> > please push the priority or signal it on it.
> >
> > Thanks!
> >
> > Antoine
> >
> >
> > On Thu, Apr 1, 2010 at 11:54, Daniel Spiewak <dj...@gmail.com>
> wrote:
> >
> >> There is a problem I found (and reported) the other day with our default
> >> versions of Specs and ScalaCheck. It can actually cause a compiler
> crash on
> >> some projects, so I think we really need to fix it before we release
> 1.4.0
> >> GA. I don't have the issue number handy right now, but it should be the
> >> only open critical issue with the Scala support.
> >>
> >> Daniel
> >>
> >>
> >> On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <an...@lunar-ocean.com>
> >> wrote:
> >>
> >> Hi, the first RC for Buildr 1.4.0 is available here:
> >>>
> >>> http://people.apache.org/~toulmean/buildr/1.4.0<http://people.apache.org/%7Etoulmean/buildr/1.4.0>
> >>>
> >>> Now is the time for testing. In two weeks, we will issue a GA release
> if
> >>> everything is smooth.
> >>>
> >>> Thanks!
> >>>
> >>> Antoine
> >>>
> >>
> >
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I trimmed down the issues for 1.4 to 17. 6 of them are assigned to me and
I'll do my best to tackle them ASAP.
Thanks,
Antoine
On Thu, Apr 1, 2010 at 12:54, Antoine Toulme <an...@lunar-ocean.com>wrote:
> I'll look at the bugs on the 1.4 roadmap tonight and will filter those to
> be fixed in subsequent releases.
>
> Here is the filter I will use:
>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310734&fixfor=12313152
>
> I hope to have a good handle over what needs to be fixed, and I'll take a
> reasonable minimalist approach. If you want your bug to be considered,
> please push the priority or signal it on it.
>
> Thanks!
>
> Antoine
>
>
> On Thu, Apr 1, 2010 at 11:54, Daniel Spiewak <dj...@gmail.com> wrote:
>
>> There is a problem I found (and reported) the other day with our default
>> versions of Specs and ScalaCheck. It can actually cause a compiler crash on
>> some projects, so I think we really need to fix it before we release 1.4.0
>> GA. I don't have the issue number handy right now, but it should be the
>> only open critical issue with the Scala support.
>>
>> Daniel
>>
>>
>> On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <an...@lunar-ocean.com>
>> wrote:
>>
>> Hi, the first RC for Buildr 1.4.0 is available here:
>>>
>>> http://people.apache.org/~toulmean/buildr/1.4.0
>>>
>>> Now is the time for testing. In two weeks, we will issue a GA release if
>>> everything is smooth.
>>>
>>> Thanks!
>>>
>>> Antoine
>>>
>>
>
Re: Buildr 1.4.0 RC1
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I'll look at the bugs on the 1.4 roadmap tonight and will filter those to be
fixed in subsequent releases.
Here is the filter I will use:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310734&fixfor=12313152
I hope to have a good handle over what needs to be fixed, and I'll take a
reasonable minimalist approach. If you want your bug to be considered,
please push the priority or signal it on it.
Thanks!
Antoine
On Thu, Apr 1, 2010 at 11:54, Daniel Spiewak <dj...@gmail.com> wrote:
> There is a problem I found (and reported) the other day with our default
> versions of Specs and ScalaCheck. It can actually cause a compiler crash on
> some projects, so I think we really need to fix it before we release 1.4.0
> GA. I don't have the issue number handy right now, but it should be the
> only open critical issue with the Scala support.
>
> Daniel
>
>
> On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <an...@lunar-ocean.com>
> wrote:
>
> Hi, the first RC for Buildr 1.4.0 is available here:
>>
>> http://people.apache.org/~toulmean/buildr/1.4.0
>>
>> Now is the time for testing. In two weeks, we will issue a GA release if
>> everything is smooth.
>>
>> Thanks!
>>
>> Antoine
>>
>
Re: Buildr 1.4.0 RC1
Posted by Daniel Spiewak <dj...@gmail.com>.
There is a problem I found (and reported) the other day with our
default versions of Specs and ScalaCheck. It can actually cause a
compiler crash on some projects, so I think we really need to fix it
before we release 1.4.0 GA. I don't have the issue number handy right
now, but it should be the only open critical issue with the Scala
support.
Daniel
On Apr 1, 2010, at 2:05 AM, "Antoine Toulme" <an...@lunar-ocean.com>
wrote:
> Hi, the first RC for Buildr 1.4.0 is available here:
>
> http://people.apache.org/~toulmean/buildr/1.4.0
>
> Now is the time for testing. In two weeks, we will issue a GA
> release if
> everything is smooth.
>
> Thanks!
>
> Antoine