Right -- that's exactly the point I was making (WIP in a sep. branch). The trouble is that's _not_ how MASTER is treated today b/c there aren't actual concrete consequences for not doing so. A harder line would need to be taken in order to ensure that a green build actually does mean "I can use this" rather than just "this build passes except for the few tests I've commented out for the time being". As mentioned, this is probably good practice anyway, so 'enforcing' it isn't per se a bad thing for the project.
But I still maintain that there is an important distinction between "it builds and is green" and "the project is at an important milestone where its stable enough to solicit broader feedback". As an example: consider the uptick in bug reports that were received after 3.3 went BETA or RC1. Its hard to argue (from my POV at least) that this is mostly attributable to the fact that the beta/RC was available via NuGet. Instead, a broader collection of people heard it was "ready enough for them to bother to take a hard look at it and test for regressions in all their important use-cases" and so took the time to do so. I know I'm apparently in the minority in my belief that there's a diff. betw. people willing to "live on the trunk" and those willing to "take their valuable limited time to test out a beta or RC", but IMO these people do in fact still exist (even if they are only driven by the 'false' sense of security/quality implicit in an 'official milestone release'). My observation (just based on past history) is there there actually *is* a distinction betw. CI builds and release milestones in re: the quality bar this project has set for itself. If we feel that the quality bar in place for beta/rc/etc. can be met for each and every CI build (at least in the MASTER branch) then I agree that the distinction may not be meaningful in the future (but it probably was in the past). Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Wed, May 30, 2012 at 8:10 AM, Diego Mijelshon <[email protected]>wrote: > 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? >>>> >>> >> >
