Do we need beta AND alpha channels?

[dankessler]

When we originally laid out the MethodsCore workflow in the wiki, each toolbox had three channels

1. stable (representing production-quality code)
2. beta (representing tested, but not yet ready-to-go code)
3. alpha (representing rapidly iterated code)

The idea was that new features would branch off of stable. The upstream flow would sort of be like hands on a clock: alpha would very frequently advance through inclusion of feature branches, beta would occasionally advance by incorporating alpha, and stable would more rarely advance by incorporating beta.

In practice, changes usually only moved from alpha -> beta when we had something we wanted to ship in a release, so we simplified the scheme to drop the stable channel so that we didn't do silly alpha -> beta -> stable merges in the space of a few minutes.

Now, I wonder if we even need the alpha/beta distinction. We have a fairly punctuated equilibrium, where tools tend to remain static for periods of time and occasionally undergo rapid changes.

I still think it's useful for us to keep the toolboxes separate from public (although one could make an argument that as our codebase matures we could adopt a more linear development strategy), but what do others on the @UMPsychMethodsCore/developers team think?

This was inspired by my code review of #375, in which I realized that ConnTool_alpha was probably merged directly into public, although also had public seemingly merged into it, then branched off of as a hotfix, and now #375 is trying to re-integrate these changes into public. As a result, ConnTool_beta is now 1884 commits behind ConnTool_alpha, which isn't such a great state of affairs. It's easy enough to fast forward ConnTool_beta -> ConnTool_alpha since there's a direct ancestry chain (i.e. no merges required), but if we have arcane policy that is causing weird messes like these, I'd rather fix the policy than keep cleaning them up :)

[rcwelsh]

Whoops - my bad ConnTool_alpha going into public. Did you merge it already into public? I can move that backwards.

So a question, though. If there is a cross-dependency of toolboxes, such as with spm8Batch and the new core_beta which holds spm8R6313, will we will do the cross tool merge?

So other hypothetical ( and I know we discuss this stuff > 3 years ago ), if say I'm doing new development in ConnTool and I want the latest of the spm8Batch and say both have histories on order of 5-10 commits, then I'd check out ConnTool_beta as a new branch, but merge in the latest spm8Batch, which would then bring ConnTool up-to-date on the spm8Batch when I do the pull request to universe/ConnnTool_beta? Other wise we'd need to have public back propagated to ConnTool_beta to get the latest spm8Batch into it.

The diagram on the standards page https://github.com/UMPsychMethodsCore/MethodsCore/wiki/Standards only reflects when working in a standalone tool that doesn't rely too much on other tools.

But I do agree with the sentiment of simplifying.

[mangstad]

I seem to remember discussing dependencies when we were working on some tool, maybe cPPI, though I don't recall what the agreed upon strategy was for that.

And it obviously becomes more complicated in a situation like this when both things are unreleased, since in the case where one of the dependencies is already released you could just point your development code to the public MethodsCore repo.

In terms of the original question, I personally like (at least the idea of) having the alpha/beta split. Though I think it was more relevant and useful in the early days when there was quite a lot of development work, now that there is less new development and more maintenance, I probably wouldn't miss it.

[dankessler]

The question of how to handle inter-toolbox dependencies is an important once, but I think we can tackle that independently of the alpha/beta question (I've opened #379 to discuss inter-dependency issues).

I also like(d) the alpha/beta split, it's just starting to feel to me like it's causing more confusion/problems than flexibility.

We could move to a hybrid approach where toolboxes that are getting more active attention have that level of granularity, but a hybrid approach may be more complicated in and of itself.

[mangstad]

I don't think a hybrid approach would help, as it would just be more confusing I think. As I just mentioned in #376 in response to Joe, I think removing the alpha channel would make the most sense since our local machines basically serve as the alpha channel where active development and testing happens. Then we'd push finalized code to beta for code review before merging into public.

[dankessler]

It seems like we're perhaps approaching a consensus on condensing the channels.

For the purposes of avoiding tons of branch renames, it'd probably be simplest to keep the _beta channels around and merge all of the alphas into betas.

Anybody have a dissenting view on this approach?

[rcwelsh]

I agree @dankessler, my vote is to merge away the alpha channels.

[dankessler]

I'm assuming @sripada is happy with whatever the developer team thinks is best, just want to get sign-off from Joe before I go and make those changes.

[dankessler]

Guess I should tag @heffjos if I want him to weigh in specifically

[heffjos]

I think it is a good idea and have not problem.

[dankessler]

Got it. I'll tweak the wiki page and start rolling alphas up into betas, then clear out the alphas

[dankessler]

Closing this, since it's resolution is handled in another issue (#382)