Hmmm, how the knowledge of broken build with latest gradle prevents us from working on experimental/internal features? Is the current state of buildSrc (incorrect imports VS latest gradle) an instance of working on experimental feature?
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 :) 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. 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
