Stephen, I believe most of those concerns would be addressed by proper use of the DVCS (which we didn't have back then). IOW, unfinished changes should go in a separate branch.
Diego On Tue, May 29, 2012 at 9:55 PM, Stephen Bohlen <[email protected]> wrote: > I'd be find with this approach, but I think you're being (potentially) > pretty liberal in assuming that each successful CI build necessarily > results in only *added* functionality. If you go back over the commit > history, there are very real instances of conditions where people have said > "this is in-progress and doesn't quite work yet so I just temporarily > commented out the failing tests for it until I can get back to dig into > exactly why they are now failing". As an example, its not uncommon for > someone to say "I've committed X but it broke some of the tests for dialect > Y so I've commented them out for the time being until I can can figure out > why". Under this model, anyone with a stable beta1 build would (probably) > end up updating to this new build full of (temporary) regression bugs. > > If the CI build isn't going to be distinguishable from "here's a stable > build we'd like the community to actually bother attempting to use and > provide feedback on" then the project needs to become much more stringent > on what gets committed to MASTER in re: whether it introduces regression > bugs (i.e., any work that requires some tests to be temporarily ignored in > order to keep the build green probably needs to be committed on a > non-MASTER branch). We can probably agree that this is *always* a good > practice anyway, but munging together the CI auto-builds with the alpha, > beta, RC, etc. makes it a practice with real consequences for even > _temporarily_ ignoring it. It will only take one or two 'oops, sorry we > broke your app' experiences for consumers of the CI builds to stop doing so > (out of self-preservation). The effect of that is that we will have lost > our mechanism for getting people to consume the beta1, beta2, RC1, etc. > builds b/c these won't any longer be distinguishable from the 'untrustable' > CI builds anymore. > > As I said, personally I'd be fine with this, but it would probably require > a different way of thinking about just how 'pristine' the state of the > MASTER branch is maintained (e.g. we'd have to maintain a zero-tolerance > policy around regression bugs at pretty much all times). As mentioned, > this is perhaps just forcing good practices on everyone anyway, but its > worth at least considering the following: does the presence of a package > manager (which not everyone will either want to or be able to use) > necessarily make it a positive move to change the process of > dev-build-QA-release? There are benefits to maintaining this distinction > too; I just want to ensure that we're considering all aspects of this > choice before we choose how to proceed :) > > > Steve Bohlen > [email protected] > http://blog.unhandled-exceptions.com > http://twitter.com/sbohlen > > > On Tue, May 29, 2012 at 8:08 PM, Seif Attar <[email protected]> wrote: > >> Howdy, >> >> Maybe I am hanging out with the wrong crowd, but the people I have spoken >> to will either use the latest stable release, or the latest build that has >> a feature they really want. >> >> Is there really 3 types of users? Speaking for myself, I know I would go >> into a pre release if it fixes a major issue I am having, or add >> functionality which I need, if tests fails with a named pre-release(alpha, >> beta ...) and I really want to start using that feature, then I would >> download the source code and hope that some commit after that release fixed >> the failing test I am facing. So even if there were this intermediary >> release which the developers of an OSS project believe is release worthy, I >> would still need to go get the latest source code. >> >> I agree with Diego that this is a problem of accessability, if the >> nightly builds were as easy to get as the beta, rc1 ... then we would not >> have the extra type of user, and it would make things simpler. What makes >> an RC1 more stable than RC1++? I know I would trust RC1++ more than RC1 >> because whatever commits happened after RC1 were solving a problem. >> >> When it comes to how versioning different aspects, I like having the >> informational version match the nuget package version and the assembly >> version to just be X.Y.0.0 which makes dropping in assemblies easier for a >> patch release and removes the need for binding redirects. >> >> >> >> On Wednesday, 23 May 2012 15:30:00 UTC+1, Alexander I. Zaytsev wrote: >>> >>> Hi all. >>> >>> I think that it would be greate if our CI-builds would be available at >>> the nuget. >>> >>> What do you think? >>> >> >
