Gradle 0.8 release

[hdockter]

We need to start thinking about a release date for Gradle 0.8.  
Possibly Sep 11. May be one week later.

@Tom What is the status for the native test runners?

Thoughts?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Hans Dockter wrote:
> We need to start thinking about a release date for Gradle 0.8.
> Possibly Sep 11. May be one week later.
>

Either is good for me. I guess this means we're not doing a 0.7.1 release?


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

> I guess this means we're not doing a 0.7.1 release?

Good point. I just had a look at the issues we have fixed for 0.7.1  
and I think none is urgent enough to justify a release. Therefore I  
have moved them all to 0.8 and removed the 0.7.1 release from Jira.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Hans Dockter wrote:
> We need to start thinking about a release date for Gradle 0.8. Possibly
> Sep 11. May be one week later.
>
> @Tom What is the status for the native test runners?
>
> Thoughts?
>
> - Hans
>

We plan on having the GUI ready to check in this week.  We would like enough
time to get some feedback on this so another week might be nice.

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tom Eyckmans]

Test pipelines and forks are now separate concepts, I need to clean up the fork test execution and add a TestNG runner, I plan to commit to trunk this week, I hope somebody can take a look at it and add some reporting because I'm going on a two week holiday from this saturday.

I'll try and add as much detail to the wiki page on the implementation details.

Kr,

Tom

2009/8/31 Steve Appling <sajakarta@...>

Hans Dockter wrote:

We need to start thinking about a release date for Gradle 0.8. Possibly Sep 11. May be one week later.

@Tom What is the status for the native test runners?

Thoughts?

- Hans

We plan on having the GUI ready to check in this week.  We would like enough time to get some feedback on this so another week might be nice.

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[hdockter]

On Aug 31, 2009, at 2:09 PM, Steve Appling wrote:

>
>
> Hans Dockter wrote:
>> We need to start thinking about a release date for Gradle 0.8.  
>> Possibly Sep 11. May be one week later.
>> @Tom What is the status for the native test runners?
>> Thoughts?
>> - Hans
>
> We plan on having the GUI ready to check in this week.  We would  
> like enough time to get some feedback on this so another week might  
> be nice.

We go for September 18 as the release date.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Murph]

Hans,

I know that Steve has been busy, so he might not have seen this yet.  Thank you for delaying the release until the 18th.  Our intent was to get the GUI checked in this week, but it has unfortunately been delayed.  Due to the long weekend (Monday is the Labor Day holiday in America) it will not be possible to get it checked in before Tue, September 8.  I thought you might like to know the progress on this item.


--
John Murph
Automated Logic Research Team

[hdockter]

On Sep 4, 2009, at 4:19 PM, Hans Dockter wrote:

>
> On Aug 31, 2009, at 2:09 PM, Steve Appling wrote:
>
>>
>>
>> Hans Dockter wrote:
>>> We need to start thinking about a release date for Gradle 0.8.  
>>> Possibly Sep 11. May be one week later.
>>> @Tom What is the status for the native test runners?
>>> Thoughts?
>>> - Hans
>>
>> We plan on having the GUI ready to check in this week.  We would  
>> like enough time to get some feedback on this so another week might  
>> be nice.
>
> We go for September 18 as the release date.

We will need a couple of more days and plan to release Gradle in w/c  
Sep 21. One thing we definitely want to have in the release are the  
onlyIf optimizations for the Java Plugin tasks.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Hans Dockter wrote:

>
> On Sep 4, 2009, at 4:19 PM, Hans Dockter wrote:
>
>>
>> On Aug 31, 2009, at 2:09 PM, Steve Appling wrote:
>>
>>>
>>>
>>> Hans Dockter wrote:
>>>> We need to start thinking about a release date for Gradle 0.8.
>>>> Possibly Sep 11. May be one week later.
>>>> @Tom What is the status for the native test runners?
>>>> Thoughts?
>>>> - Hans
>>>
>>> We plan on having the GUI ready to check in this week.  We would like
>>> enough time to get some feedback on this so another week might be nice.
>>
>> We go for September 18 as the release date.
>
> We will need a couple of more days and plan to release Gradle in w/c Sep
> 21. One thing we definitely want to have in the release are the onlyIf
> optimizations for the Java Plugin tasks.
>
> - Hans
>

Please don't rush to release 0.8 if there are items that still aren't ready.  I
have a few concerns:

* The javadoc for gradle-core still fails.
* The userguide needs to build under windows.
* We still need some userguide content for Source Sets.
* Source Set language checking - I still don't know how to check to see what
types of source (java, groovy, scala) are in a source set.  This is keeping me
from making a simple change.
* I think we need time to digest (and exercise) source sets before the release.
  This is a big change and I don't feel like I understand it well enough to use
it before the documentation is done.  While I have a lot of confidence in the
quality of Adam's work, I think a change of this scope could use some feedback
based on real use.  After it is documented and I understand it, I'll be glad to
try to apply it on our system and give some of that feedback.
* Small GUI changes.  We have a handful of small changes to help clean up the
GUI that I hope to apply tomorrow.
* Listener Management - John has been working on making a listener manager that
we need to get our Team City plugin working.  We would love to have this in 0.8.
  I think this will be ready in a day or so as well.

It would probably be good to have a checklist of remaining items like this that
need to be finished before 0.8.



--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Appling wrote:

>
>
> Hans Dockter wrote:
>>
>> On Sep 4, 2009, at 4:19 PM, Hans Dockter wrote:
>>
>>>
>>> On Aug 31, 2009, at 2:09 PM, Steve Appling wrote:
>>>
>>>>
>>>>
>>>> Hans Dockter wrote:
>>>>> We need to start thinking about a release date for Gradle 0.8.
>>>>> Possibly Sep 11. May be one week later.
>>>>> @Tom What is the status for the native test runners?
>>>>> Thoughts?
>>>>> - Hans
>>>>
>>>> We plan on having the GUI ready to check in this week.  We would
>>>> like enough time to get some feedback on this so another week might
>>>> be nice.
>>>
>>> We go for September 18 as the release date.
>>
>> We will need a couple of more days and plan to release Gradle in w/c
>> Sep 21. One thing we definitely want to have in the release are the
>> onlyIf optimizations for the Java Plugin tasks.
>>
>> - Hans
>>
>
> Please don't rush to release 0.8 if there are items that still aren't
> ready.  I have a few concerns:
>

I think we need a couple more days as well.

> * The javadoc for gradle-core still fails.

I would put this low on the priority list. I don't think we care about
this for the release, relative to the other items on this list.

> * The userguide needs to build under windows.

The html userguide does. We don't release from windows, so I would put
this low on the list.

> * We still need some userguide content for Source Sets.

Absolutely. It's on its way.

> * Source Set language checking - I still don't know how to check to
> see what types of source (java, groovy, scala) are in a source set.  
> This is keeping me from making a simple change.

As mentioned in another email, you shouldn't need to. And if you do, you
would use the same mechanism you've always used, ie has the
java/groovy/scala plugin been applied to the project?

> * I think we need time to digest (and exercise) source sets before the
> release.  This is a big change and I don't feel like I understand it
> well enough to use it before the documentation is done.  While I have
> a lot of confidence in the quality of Adam's work, I think a change of
> this scope could use some feedback based on real use.  After it is
> documented and I understand it, I'll be glad to try to apply it on our
> system and give some of that feedback.

I think the whole point of doing the release is to get feedback. I
wouldn't hold off the release for this, but if you have feedback
beforehand, then we can incorporate it before the release.

> * Small GUI changes.  We have a handful of small changes to help clean
> up the GUI that I hope to apply tomorrow.

I guess you have a few days to apply this.

>
> * Listener Management - John has been working on making a listener
> manager that we need to get our Team City plugin working.  We would
> love to have this in 0.8.  I think this will be ready in a day or so
> as well.
>

I will apply this soon.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Murph]

On Mon, Sep 21, 2009 at 5:53 PM, Adam Murdoch <a@...> wrote:

<snip>
 

As mentioned in another email, you shouldn't need to. And if you do, you would use the same mechanism you've always used, ie has the java/groovy/scala plugin been applied to the project?

Isn't that weird though, to query if one concept (project) has been extended in order to infer if another concept (source sets) has been extended?  This goes to the other discussion, that extensions are a more "universal" concept.  If so, then each extensible thing needs a way to know if it's been extended in a given direction.  For now, though, I think checking if a given plugin has been used is good enough.

<snip>

* Listener Management - John has been working on making a listener manager that we need to get our Team City plugin working.  We would love to have this in 0.8.  I think this will be ready in a day or so as well.

I will apply this soon.

Don't.  Steve confirmed today that the failing integration tests are really my fault.  I'm still trying to understand what I did wrong, but I think I'll have it fixed tomorrow (I ran out of time today, what with all the flooding here in Atlanta).  I'll have Steve commit it when I'm done, as I think we have agreed on the last changes (other than working out the bugs...).

--
John Murph
Automated Logic Research Team

[hdockter]

On Sep 21, 2009, at 10:30 PM, Steve Appling wrote:

>
>
> Hans Dockter wrote:
>> On Sep 4, 2009, at 4:19 PM, Hans Dockter wrote:
>>>
>>> On Aug 31, 2009, at 2:09 PM, Steve Appling wrote:
>>>
>>>>
>>>>
>>>> Hans Dockter wrote:
>>>>> We need to start thinking about a release date for Gradle 0.8.  
>>>>> Possibly Sep 11. May be one week later.
>>>>> @Tom What is the status for the native test runners?
>>>>> Thoughts?
>>>>> - Hans
>>>>
>>>> We plan on having the GUI ready to check in this week.  We would  
>>>> like enough time to get some feedback on this so another week  
>>>> might be nice.
>>>
>>> We go for September 18 as the release date.
>> We will need a couple of more days and plan to release Gradle in w/
>> c Sep 21. One thing we definitely want to have in the release are  
>> the onlyIf optimizations for the Java Plugin tasks.
>> - Hans

I'm sick in bed with a fever and couldn't do any work in the last  
days. I will also need some more days to get some stuff done.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Adam Murdoch wrote:

>
>
> Steve Appling wrote:
>> Please don't rush to release 0.8 if there are items that still aren't
>> ready.  I have a few concerns:
>>
>
> I think we need a couple more days as well.
>
>> * The javadoc for gradle-core still fails.
>
> I would put this low on the priority list. I don't think we care about
> this for the release, relative to the other items on this list.
>

I think it would be bad to release all of this new functionality without anyone
being able to use the documentation for it.  The javadoc is (should be) a very
useful reference.

>> * The userguide needs to build under windows.
>
> The html userguide does. We don't release from windows, so I would put
> this low on the list.
>
I am mainly concerned about this because I think it may be an indicator of some
underlying memory management problems. I know that I have had to wrestle with
combinations of Xmx and permgen sizes almost each time I make a change.  It does
not seem that Gradle should be such a large and complicated project to require
the memory we do.  I worry about the scalability if we can't build ourself well.

>> * We still need some userguide content for Source Sets.
>
> Absolutely. It's on its way.
>
>> * Source Set language checking - I still don't know how to check to
>> see what types of source (java, groovy, scala) are in a source set.  
>> This is keeping me from making a simple change.
>
> As mentioned in another email, you shouldn't need to. And if you do, you
> would use the same mechanism you've always used, ie has the
> java/groovy/scala plugin been applied to the project?
>

I will just check the plugin (for some reason I didn't get that other email
until this morning), but it seems somehow wrong.  Testing the use of the plugin
seems disconnected from using the source set properties.  I think I should be
able to check for the validity of the source set members as well at some point.

>> * I think we need time to digest (and exercise) source sets before the
>> release.  This is a big change and I don't feel like I understand it
>> well enough to use it before the documentation is done.  While I have
>> a lot of confidence in the quality of Adam's work, I think a change of
>> this scope could use some feedback based on real use.  After it is
>> documented and I understand it, I'll be glad to try to apply it on our
>> system and give some of that feedback.
>
> I think the whole point of doing the release is to get feedback. I
> wouldn't hold off the release for this, but if you have feedback
> beforehand, then we can incorporate it before the release.
>

I don't feel that I have enough understanding of source sets to provide the
feedback now - and I don't know that I will get that until the documentation is
done.  Perhaps the Gradle community has a different view of releases than I am
used to.  I am used to having significant changes like this exercised by a group
of core users (often through an alpha or preview release).  A preview release
should have enough documentation so that people can exercise the new features,
but the implementation itself is more open to change.  A more "real" public
release will cause larger groups of people to update their builds to accommodate
incompatible changes and will make other changes due to feedback more painful.

>> * Small GUI changes.  We have a handful of small changes to help clean
>> up the GUI that I hope to apply tomorrow.
>
> I guess you have a few days to apply this.
>
>>
>> * Listener Management - John has been working on making a listener
>> manager that we need to get our Team City plugin working.  We would
>> love to have this in 0.8.  I think this will be ready in a day or so
>> as well.
>>
>
> I will apply this soon.
>

I helped John find some issues with this and I can apply it if you have no
objections.

>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Appling wrote:

>
>
> Adam Murdoch wrote:
>>
>>
>> Steve Appling wrote:
>>> Please don't rush to release 0.8 if there are items that still
>>> aren't ready.  I have a few concerns:
>>>
>>
>> I think we need a couple more days as well.
>>
>>> * The javadoc for gradle-core still fails.
>>
>> I would put this low on the priority list. I don't think we care
>> about this for the release, relative to the other items on this list.
>>
> I think it would be bad to release all of this new functionality
> without anyone being able to use the documentation for it.  The
> javadoc is (should be) a very useful reference.
>

Absolutely. We generate the javadoc for the release using :javadoc,
which generates the combined docs for all projects, rather than using
:gradle-core:javadoc.

Having said that, it's bad form to have broken tasks in the build. I'll
try to fix it before the release. I'd rather :gradle-code:javadoc didn't
exist, as we don't care about its output. I might 'fix' it by disabling it.

>>> * The userguide needs to build under windows.
>>
>> The html userguide does. We don't release from windows, so I would
>> put this low on the list.
>>
> I am mainly concerned about this because I think it may be an
> indicator of some underlying memory management problems. I know that I
> have had to wrestle with combinations of Xmx and permgen sizes almost
> each time I make a change.  It does not seem that Gradle should be
> such a large and complicated project to require the memory we do.  I
> worry about the scalability if we can't build ourself well.
>

Quite possibly. I will try to have a look in the next couple of days.

>>> * We still need some userguide content for Source Sets.
>>
>> Absolutely. It's on its way.
>>
>>> * Source Set language checking - I still don't know how to check to
>>> see what types of source (java, groovy, scala) are in a source set.  
>>> This is keeping me from making a simple change.
>>
>> As mentioned in another email, you shouldn't need to. And if you do,
>> you would use the same mechanism you've always used, ie has the
>> java/groovy/scala plugin been applied to the project?
>>
> I will just check the plugin (for some reason I didn't get that other
> email until this morning), but it seems somehow wrong.  Testing the
> use of the plugin seems disconnected from using the source set
> properties.  I think I should be able to check for the validity of the
> source set members as well at some point.
>

Absolutely.  It's a matter of priorities at this stage. I think its more
important to end up with a solution where most people don't need to care
about what's been applied. And for those that do care, I think we have
an acceptable, if not ideal, solution by checking which plugins have
been applied to the project.

>>> * I think we need time to digest (and exercise) source sets before
>>> the release.  This is a big change and I don't feel like I
>>> understand it well enough to use it before the documentation is
>>> done.  While I have a lot of confidence in the quality of Adam's
>>> work, I think a change of this scope could use some feedback based
>>> on real use.  After it is documented and I understand it, I'll be
>>> glad to try to apply it on our system and give some of that feedback.
>>
>> I think the whole point of doing the release is to get feedback. I
>> wouldn't hold off the release for this, but if you have feedback
>> beforehand, then we can incorporate it before the release.
>>
> I don't feel that I have enough understanding of source sets to
> provide the feedback now - and I don't know that I will get that until
> the documentation is done.

I guess that's some feedback right there.

>   Perhaps the Gradle community has a different view of releases than I
> am used to.  I am used to having significant changes like this
> exercised by a group of core users (often through an alpha or preview
> release).  A preview release should have enough documentation so that
> people can exercise the new features, but the implementation itself is
> more open to change.  A more "real" public release will cause larger
> groups of people to update their builds to accommodate incompatible
> changes and will make other changes due to feedback more painful.
>

I'm not sure that it is such a high impact change. If you're following
the convention, you won't need to do anything. Given the limited options
for configuring the project layout in 0.7, there's a simple
transformation for converting this configuration to 0.8.

So far, we've been relying on people using trunk to give feedback.
Source sets have been in trunk for over a month now, and we've been
using them for Gradle's build for about 3 weeks. That feels like enough
time to shake it out.

I guess at some point we will start doing preview releases. I'm not sure
how we figure out when it's worth the effort to do so. Certainly by the
time we get to 1.0.

>
>>> * Small GUI changes.  We have a handful of small changes to help
>>> clean up the GUI that I hope to apply tomorrow.
>>
>> I guess you have a few days to apply this.
>>
>>>
>>> * Listener Management - John has been working on making a listener
>>> manager that we need to get our Team City plugin working.  We would
>>> love to have this in 0.8.  I think this will be ready in a day or so
>>> as well.
>>>
>>
>> I will apply this soon.
>>
> I helped John find some issues with this and I can apply it if you
> have no objections.
>

No objections. John's changes look good.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email