[Webtest] [dev] roadmap or who is doing what

[Paul King]

+1 for keeping number of branches low (assuming Marc is happy
with branches)

(I would want at most one branch that I would have to think
about apart from HEAD and would only want to think about it
during a small release window.)

I am happy with a temporary branch for new non-release code
that would be merged back after the release. The implication
is that we couldn't as easily do a "patch" update of an older
release, e.g. if we found a security hole in 1.6 for example.

We have tried this type of branching on other projects
but gave up as it seemed to be more confusing for some
developers - the feedback was that some tools weren't as
geared up to merge as easily in that direction but that
was a while ago - happy to give it another try and we can
see what happens.

Cheers, Paul.

Dierk Koenig wrote:
> +1
> 
> Concerning branches, I know that not everybody likes that.
> 
> For me it is ok and Denis is a real expert in it.
> If it's ok for you and Marc, than we can go this way.
> 
> Concerning (3) below I'd rather suggest that we keep the
> development stream 'to be released' on the trunk and commit
> anything that needs to committed but will not make it into
> the release on a separate branch (e.g. the 1.8 branch)
> rather than vice versa.
> 
> That way:
> - the 'to be released' version is most easy to identify
> - only the 'to be released' version is subject to cruise
> - the developer that needs the extra branch can decide whether
>   he wants to go for the branch version or whether he can live
>   with a local 'dirty' state for a few days
> 
> The latter is for keeping the number branches low
> since merging branches to the trunk after release is always a bit
> of extra effort.
> 
> cheers
> Mittie
> 
> 
>>-----Original Message-----
>>From: webtest-admin@lists.canoo.com
>>[mailto:webtest-admin@lists.canoo.com]On Behalf Of Paul King
> 
> 
>>(3) when freeze date arrives we make a branch/tag for the release
>>(at that point any changes for the release would need to be merged
>>onto the branch and HEAD, whereas any changes not destined for
>>the release would just go to HEAD)
>>[this addresses Marc's concern as anyone without time can simply
>>ignore releases and commit to HEAD]
>>
>>The only question is whether cruise knows about releases. For the two
>>weeks during the freeze do we get cruise to build "release x.y RC"
>>releases and anyone wanting HEAD would need to do manual builds
>>or do we keep cruise on HEAD and make the x.y release manual once
>>we have all the Jira issues that we promised fixed.
>>
>>We have lots of options - we should try to keep it light weight. :-)
>