[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jmeter-dev
Subject:    Re: 2.1 release
From:       Michael Stover <mstover1 () apache ! org>
Date:       2005-06-29 3:09:21
Message-ID: 1120014561.3906.36.camel () localhost ! localdomain
[Download RAW message or body]

Creating a release branch is part of the process.  It's what allows new
development to happen without interfering with version 2.1

-Mike

On Tue, 2005-06-28 at 23:18 +0100, sebb wrote:
> +1 to 2.1 RC
> 
> Not sure that we need a 2.1 branch though.
> 
> S.
> On 6/28/05, Peter Lin <woolfel@gmail.com> wrote:
> > +1
> > 
> > hurray, we're releasing more often
> > 
> > peter
> > 
> > On 6/28/05, Michael Stover <mstover1@apache.org> wrote:
> > > I'm of the opinion we should get a 2.1 release candidate out there.  We
> > > can work on the documentation and some bugs after an candidate release
> > > just as well as before.  Shall I branch 2.1 in CVS?
> > >
> > > -Mike
> > >
> > > On Tue, 2005-06-21 at 14:32 -0400, Peter Lin wrote:
> > > > What else do we need to do for the 2.1 release :)
> > > >
> > > > peter
> > > >
> > > >
> > > > On 6/15/05, Michael Stover <mstover1@apache.org> wrote:
> > > > > To "fix" runtime controller, you could put the endOfLoop() check
> > > > > directly in the next() method.  That way, it will know to return null as
> > > > > soon as its time is up.  As it is currently, it only checks this if it's
> > > > > nextIsNull() method is ever called, which it won't be in the case
> > > > > presented in that bug - ie, where it's child is a forever loop.
> > > > >
> > > > > This change would affect the controller, which currently only stops a
> > > > > run at boundaries of its children (ie, after its last child sampler, or
> > > > > the last child controller goes).  This has the positive effect of
> > > > > treating the Runtime Controller's children as an inviolable group of
> > > > > requests that either all go, or none.  If we make this change, then the
> > > > > Runtime Controller halts operation as soon as the time is up, even if
> > > > > it's on the third sampler of five.
> > > > >
> > > > > I don't see a third alternative, because the Loop Controller, when set
> > > > > to infinite, never sends any signals to its parent controllers on when
> > > > > it starts a new loop.  To its children, yes, but not the parents.  Which
> > > > > means for the Runtime Controller to decided "enough is enough", it has
> > > > > to make the decision arbitrarily, with no notion of where in its cycle
> > > > > the Loop Controller is at.
> > > > >
> > > > > Frankly, I think the scenario presented in the bug is one of the more
> > > > > obvious use-cases of the Runtime Controller, and I think it should be
> > > > > changed as I suggest.  The docs would need to reflect the behavior
> > > > > change.
> > > > >
> > > > > -Mike
> > > > >
> > > > > On Wed, 2005-06-15 at 19:49 +0100, sebb wrote:
> > > > > > Various JMS test elements have no documentation - Peter, are you doing
> > > > > > all of these ?
> > > > > > - Messaging Request
> > > > > > - JNDI Default Configuration
> > > > > > - LDAPArgument List
> > > > > >
> > > > > > I can create empty place-holders, but I don't know enough to be able
> > > > > > to document them.
> > > > > >
> > > > > > There's a "new" bug in Runtime Controller - see
> > > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35059
> > > > > >
> > > > > > I must have broken that when I fixed various other problems with the
> > > > > > If, While and Once only controllers. Unfortunately I don't know how to
> > > > > > fix it without breaking the others ...
> > > > > >
> > > > > > AFAIK, there's no test case for the RT C, which is presumably why the
> > > > > > problem was not noticed earlier. I'm fairly sure that I can create a
> > > > > > test-case, but fixing it is another matter.
> > > > > >
> > > > > > There are of course other bugs, but the RT used to work, so it would
> > > > > > be good if it could be fixed.
> > > > > >
> > > > > > I still want to do some more fixes on HTTPsamplers and SampleResult
> > > > > > etc, but they can wait.
> > > > > >
> > > > > > BTW, the test load and save tests are failing because various extra
> > > > > > fields are being saved.
> > > > > >
> > > > > > S.
> > > > > > On 6/15/05, Peter Lin <woolfel@gmail.com> wrote:
> > > > > > > I will finish writing the jms topic how-to and update the index number
> > > > > > > this weekend.
> > > > > > >
> > > > > > >
> > > > > > > peter
> > > > > > >
> > > > > > >
> > > > > > > On 6/15/05, Michael Stover <mstover1@apache.org> wrote:
> > > > > > > > What needs doing before we can release 2.1?  As far as I'm concerned,
> > > > > > > > we're ready for at least a release candidate.  Sebb - any todos
> > > > > > > > outstanding?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

-- 


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]