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
