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? >> >
