river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Open discussion on development process
Date Thu, 29 Nov 2012 14:27:53 GMT
On 29 November 2012 13:11, Peter Firmstone <jini@zeus.net.au> wrote:

> The last passing trunk versions:
>
> Jdk6 Ubuntu     1407017
> Solaris  x86        1373770
> Jdk7 Ubuntu     1379873
> Windows           1373770
>
> Revision 1373770 looks the most stable, I think all platforms were passing
> on this,  1407017 only passed on Ubuntu jdk6, nothing else.
>
> If we can confirm 1373770 as stable, maybe we should branch a release off
> that, buying some time to stabilise what we're working on now.
>
>
I think we should do that. I'm also tempted to suggest we consider limiting
our development until we've fixed these tests up. Or alternatively control
the rate of patch merging so we can pace it and make sure the tests get
focus.

That's a bit sledgehammer but...


> Need to check that jdk7 ubuntu passes on 1373770, otherwise 1379873 might
> be the one to branch off, maybe try 1379873 first.
>
> Cheers,
>
> Peter.
>
>
> On 29/11/2012 10:24 PM, Simon IJskes - QCG wrote:
>
>> On 29-11-12 13:07, Peter Firmstone wrote:
>>
>>> On 29/11/2012 10:04 PM, Simon IJskes - QCG wrote:
>>>
>>
>>
>>>> How about the following, we develop on a branch. Then we merge or
>>>> patch. We release. We pull a new branch of trunk. We merge/patch stuff
>>>> that did not make it in the release from the previous dev branch into
>>>> the current dev branch. (we can skip rebranching if we want to keep
>>>> the old dev branch).
>>>>
>>>> It looks like a lot more work, but i suspect river-core will only get
>>>> small changes, and the rest will end up in other subprojects.
>>>>
>>>>
>>> Ok, sounds like a plan.
>>>
>>
>> Shall i do a 'switch-and-stitch' with trunk and new dev-branch? Do you
>> have a revision number from just before the bugfix experiments in
>> RegistrarImpl? We could make that the new trunk. And the current trunk the
>> dev-branch. I can do it in such a way, the revision history is kept clean.
>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message