I'm very fond of git-flow:
http://nvie.com/posts/a-successful-git-branching-model/
This model makes it pretty clear which tasks happen when and where in the
repository, and it (mostly) decouples feature accumulation in the develop
branch from stabilization work in the release branch.
Best Regards, David
On Wed, 30 May 2012 09:10:58 -0300, 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?
>>>>
>>>
>>
