On 09/01/2012, at 9:34 PM, Szczepan Faber wrote: > Hmmm, how the knowledge of broken build with latest gradle prevents us from > working on experimental/internal features?
It doesn't. However, if we want to do this, then we have to give up using the build as a stability test. We can't have all 3 options at once. > Is the current state of buildSrc (incorrect imports VS latest gradle) an > instance of working on experimental feature? This is using internal classes. > > Yesterday, I had exactly the same case as Daz. I wanted to run build with > latest gradle and the buildSrc failed. Yeah, I can investigate, find the > imports to fix, etc. However, it feels that the it should work... Chance is > there are (will be) other people in the community with the same use case. > > Generally, it feels like a good idea to have quicker feedback and more > pressure to update the wrapper rather quickly when we do changes that break > the build with latest gradle :) Of course. This is the 'functional test' piece I was talking about. It's a good thing to do. The problem is that if we do this, then we give up using the build as a stability test. And as I said, we have plenty of functional test coverage already and no stability test suite. So, until we have a stability test suite to replace using the build, we should continue to use it for stability testing, not functional testing. There are some other things we might do to make breakages less likely: * Split the documentation tasks out of buildSrc, to become a regular subproject. These use internal and experimental features. And they should. Plus they need to move out of buildSrc at some point, anyway. * Release as often as possible. * Add the functional test, but switch it off during the release candidate soak period. > > On the side note, I see that UncheckedException is not a private class so the > refactoring is a potentially breaking change :/ As usual, I'd like to vote > for always considering the deprecation strategy for such things / mention in > the migration guide. UncheckedException is an internal class. We can change it as we choose. Public classes are here: http://gradle.org/docs/current/javadoc/index.html and http://gradle.org/docs/current/groovydoc/index.html. Internal classes are everything else. > > Cheers! > > On Mon, Jan 9, 2012 at 10:47 AM, Luke Daley <[email protected]> wrote: > On 09/01/2012, at 4:58 AM, Adam Murdoch <[email protected]> wrote: > >> >> On 09/01/2012, at 10:48 AM, Daz DeBoer wrote: >> >>> On 8 January 2012 14:29, Adam Murdoch <[email protected]> wrote: >>> >>> On 09/01/2012, at 3:46 AM, Daz DeBoer wrote: >>>> I think the recent code restructure has made some things unavailable to >>>> our buildSrc project. I started to clean them up, but it wasn't as simple >>>> as a few package changes. >>>> Would be good to have a CI build that used the Gradle nightly to build >>>> gradle. This would give us confidence to recommend the nightly to >>>> bleeding-edge users. >>> >>> Isn't this what our integration tests are for? >>> >>> The downside to using the nightly build to build from source is that it >>> becomes difficult for us to use internal or experimental stuff in our >>> build/buildSrc. >>> >>> I'm not sure what you mean. I don't see how this would prevent us from >>> using new features. On the contrary, we'd be forced to keep our build >>> up-to-date with the latest experimental features and changes, which might >>> be a pain. Perhaps it's that pain that you're referring to as "difficult"? >>> >>> I don't see the harm in finding out early when we've broken a feature that >>> our build depends on. Chances are in this case we'll be breaking other >>> people's builds as well. >> >> We want to do the following 3 things with our build: >> * Use internal and experimental features. >> * Use our build as a functional test, by using a nightly build to build >> Gradle. >> * Use our build as a stability test, by using the release candidate to build >> Gradle over the release candidate soak period. >> >> We can only choose 2 out of these 3 things. We can't use the build for all 3 >> things at once. So, in order to use our build as a functional test, we'd >> either have to drop using stuff that can change, or using the build as a >> stability test. Given that we already have an extensive functional test >> suite and no stability test suite, I think we should keep using the build >> for stability testing for now. > > Do we also think of the build as a best practice example? > > If so, I'm not sure we give it the appropriate level of attention. I could be > wrong on this though as it may be just lack of historical understanding that > leaves me with this feeling. > > In any case, I'm not proposing we do anything pre 1.0. > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
