Ok, it makes sense, now I understand better what you meant by stability tests.
Cheers! On Mon, Jan 9, 2012 at 10:47 PM, Adam Murdoch <[email protected]>wrote: > > 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.htmland > 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 > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
