On 14/05/2012, at 12:00 AM, Adam Murdoch wrote: >> I think my reluctance stems from using a secondary use case to drive the >> work, potentially leading to a short lived solution. This is a rather >> intangible argument though, so I'll withdraw it. > > This is a reasonable concern. However, this isn't the only use case we'll be > using to drive the configuration model. It just happens to be the first one I > wrote up. We'll be considering a few others before we start this work. And > the order that we tackle stuff might change based on this. > > As far as preventing short lived solutions go, I think this is a potential > problem with any use case that we solve, where we later discover other use > cases that are awkward or don't work with the solution. Some things I think > we want to do a little different, to help with this: > > First, I think we want to do a little more design up front, to consider the > use cases we already know about. Up to now, we've been doing design on demand > as we're writing the code, and sometimes I think we make mistakes that a > little more thinking time might have prevented. I'm trying to do this with > the configuration model and dependency model changes we're planning (hence > these emails; the results are captured in subprojects/docs/src/design-docs).
I like the idea of doing a little more design up front. > However, the reality is that we will make design mistakes, and we need a way > to deal with this. Part of this is our add-deprecate-remove approach. To > improve this, I think we want a way to mark DSL elements as experimental and > subject to change without migration (or with limited migration). Currently, > we're either marking a lot of stuff as internal that should really be marked > as experimental, which prevents people from using it, or marking it as public > when it's not quite ready, so preventing us from fixing mistakes. Instead, > we'd have 3 classes of code (from a user's point of view): > > * Public - documented, and once included in an rc release, is stable until > the next major version. May be deprecated, with a replacement, before the > next major version. Generally, we do not remove support for any use cases, > but we may change how they are solved. > * Experimental - documented, but marked as experimental in the documentation. > Once included in an rc release, is stable only for that minor release (i.e. > if included in 1.1-rc-1, will be stable for 1.1-rc-2 and 1.1, but not > 1.2-rc-1). May change between releases, sometimes with a short deprecation > period. As for public features, we generally do not remove support for any > use case, but may change how they are solved. > * Internal - not documented. May change or disappear at any time, including > between rc releases (unlikely, but possible). I like the idea here. > btw, does anyone have suggestions for a better term than 'experimental'? “incubating” ? -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
