jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Release a 3.0
Date Thu, 14 Jan 2016 14:16:45 GMT
Hi all,
Can we go for a 3.0 or do we need to discuss it more or eventually run a
vote on this ?

Thanks
Regards

On Wed, Jan 13, 2016 at 10:18 PM, Antonio Gomes Rodrigues <ra0077@gmail.com>
wrote:

> Hi
>
> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <philippe.mouawad@gmail.com>:
>
> > On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues <
> ra0077@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > My opinion
> > >
> > > I think it's a good idea to rename to 3.0 the next release, because:
> > > Old release of JMeter have bad reputation (complex to use, bad
> > performance,
> > > etc.) to people
> > > People think that JMeter evolve slowly (I have even heard it from an
> > Apache
> > > (not JMeter) commiter
> > > Same reason than Milamber
> > >
> > > Remove old things (HC3.1 support, etc.) is great to because each time I
> > > show JMeter to someone, he is afraid by the GUI
> > >
> > > Remove some listener is great to (the two proposed by Philippe Mouawad)
> > and
> > > maybe other (I think about Monitor Results,
> >
> > +1 I think there are now better ways to do this and jmeter-plugins has 1
> >
> >
> > > Graph Results,
> >
> > +0, It can be useful in Debugging maybe
> >
> >
> > > Assertion Results
> > >
> > I prefer your idea of debug listener than removal, because from
> > Stackoverflow questions, I think this one is used
> >
> > >
> > > About listener I think it will be great to brain storming about them
> > > because I think:
> > > they are not modern
> > > it misses some very interesting/important (some are present in JMeter
> > > plugins) while JMeter have some very few helpfull
> > >
> >
> > I tend to think that new report dashboard feature answers this. As we do
> no
> > favor GUI testing, I am not sure we should enhance this with.
> > For live graphing, we should I think enhance BackendLIstener with a JDBC
> > persister at least.
> >
> I think too
>
> My complete opinion
> Have the new report dashboard feature to have a complete report at the end
> of the load test
> Have BackendLIstener to live graphing. Have a great live graphing allow to
> check the load test and stop/modify it if it's necessary (bad
> configuration, bad data, etc.). It's usefull too for some test (for example
> chekc in live the result of a chaos monkey)
> Only keep a few listeners in JMeter core (deprecate it and remove it)
> Install JMeter Plugins to have more listener if we want to display graphic
> in JMeter
>
>
> For the moment I have not test report dashboard feature but the screenshot
> I have seen are great. I will check them asap to check if something is
> missing
>
> About BackendLIstener I have already test it and it's great. Maybe it need
> some GUI improvement and new supported backend (ElasticSearch, database)
>
>
> >
> >
> > >
> > > I think it will be great to separate the listener in two parts:
> > >
> > Nice idea.
> >
> >
> > > listener (all the interesting listener (Aggregate Graph, Response Time
> > > Graph, etc.)
> > > debug listener (Assertion Results, JSR223 Listener, etc.)
> > >
> > > It will be great to have project which regroup jmx files + results +
> data
> > > files like commercial tools (a zip file is sufficient)
> > >
> > Can you clarify this ?
> >
> Instead having one or more JMX files + data files (csv) + result load test
> files (csv, etc.) I think it will be better to have a single file which
> contains all these files.
> Or two files (one for the load scripts + data and the other for the results
> files)
>
> It will allow to easily send to a collegue the complete script with all
> necessary files (csv, etc.)
> The same to send the result of a load test
>
>
>
> >
> > >
> > > It will be great to have 2 modes to hide some sampler/listener/etc.
> > > One for newcomer and another for expert.
> > > It will allow to don't scary newcomers the first time he launch JMeter
> > >
> > I like this idea, knowing that we have this property that we could use:
> > #jmeter.expertMode=true
> >
> > >
> > > Or have one mode by technology tested (http, database, etc.) + expert
> > mode
> > > will all
> > >
> > > Maybe remove some timer (I don't know is they are all used)
> > >
> > I think that all of them have their use but maybe put some only in expert
> > mode.
> >
> > Another field of deprecation is maybe the BSF elements that seem to me
> > better replaced by JSR223 elements.
> >
>
> +1
>
> >
> > Anyway thanks for all those ideas.
> >
> > >
> > > Antonio
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2016-01-08 0:48 GMT+01:00 Milamber <milamber@apache.org>:
> > >
> > > > Hello,
> > > >
> > > > For me, the jump to 3.0 must be done for next version.
> > > >
> > > >
> > > > Remember: JMeter 2.0.0 was release in 2004, so 12 years ago and 23
> > > > versions have been release since!
> > > >
> > > > A lot of works since 2004 on the user interface (the toolbar, sampler
> > > > forms, graphical listener, etc.)
> > > >
> > > > A lot of works under the woods, to improve the JMeter internal
> > > > performance, the samplers like HTTP request (default HC4), the
> parallel
> > > > resource download, etc)
> > > >
> > > > A lot of works to improve the user experience (like the Regexp
> tester,
> > > the
> > > > templates box, the search on the JMeter tree, log pane, OS
> integration
> > > for
> > > > copy/paste, POST body for WS request, etc.)
> > > >
> > > > Recently, a lot of works on the website to refresh the design (and
> > logo)
> > > > (a lot of this changes will publish on the next release)
> > > >
> > > > IMHO, the bump to JMeter 3.0, exceptionally can not only based on the
> > new
> > > > behaviors since the previous version (N-1) or API changes, but we
> need
> > to
> > > > consider the works of all developers since 2004. (and after change
> to a
> > > new
> > > > number rules)
> > > >
> > > >
> > > > Apache JMeter isn't comparable with project like Commons or
> HTTPClient
> > on
> > > > the versions rules. Commons/HC are mainly use as a framework inside
> > > another
> > > > software (like JMeter). JMeter is mainly use a as end user software,
> > the
> > > > API (break/don't break) isn't the alone criteria to change the
> versions
> > > > number. The UI and the engine must be consider to the next release
> > > number.
> > > >
> > > > Last reason to change : The users may be confused with a 2.x version
> > from
> > > > 2004 (works only with Java 1.4, some jvm args are now incompatibles)
> > and
> > > a
> > > > 2.14 version which require Java 7.
> > > >
> > > >
> > > > Milamber
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 05/01/2016 11:01, sebb wrote:
> > > >
> > > >> On 4 January 2016 at 18:23, Philippe Mouawad <
> > > philippe.mouawad@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> First Happy new year 2016 !
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <sebbaz@gmail.com>
wrote:
> > > >>>
> > > >>> JMeter does not have a formal policy for major/minor version
> release
> > > >>>> updates.
> > > >>>> However historically major veresion changes have been associated
> > with
> > > >>>> major changes.
> > > >>>>
> > > >>>> I am proposing to follow what seems to become a standard in
> > versioning
> > > >>> refering to a proposal from a scientist working on the subject.
> > > >>>
> > > >> http://semver.org/ says:
> > > >>
> > > >> Increment the MAJOR version when you make incompatible API changes,
> > > >>
> > > >> We are not doing that.
> > > >>
> > > >> Also other ASF projects such as Commons and HttpClient require major
> > > >>>> version bumps when removing deprecated code.
> > > >>>>
> > > >>>> So isn't this what we are doing as we dropped 4 classes
> > corresponding
> > > to
> > > >>> deprecated elements. And we will deprecate some more.
> > > >>> But the main idea behind this is that next version contains major
> > > >>> features
> > > >>> which I think deserve this change.
> > > >>>
> > > >> What features are you referring to?
> > > >>
> > > >>
> > > >>> I don't think the proposed changes warrant a major version bump.
> > > >>>>
> > > >>>> I don't understand, but if we don't come to an agreement I
propose
> > to
> > > >>> run a
> > > >>> vote on this although it would be better to avoid it.
> > > >>>
> > > >>> On 3 January 2016 at 15:36, Milamber <milamber@apache.org>
wrote:
> > > >>>>
> > > >>>>> I agree with a new release with a new version number system,
and
> > with
> > > >>>>> the
> > > >>>>> next release to become 3.0.
> > > >>>>>
> > > >>>>> Before the next release, I would like add the HiDPI (high
> > definition
> > > >>>>>
> > > >>>> screen)
> > > >>>>
> > > >>>>> for JMeter (for Linux Gnome/GTK and Windows). Currently
I works
> on
> > > >>>>> this.
> > > >>>>> (my new computer have a 3200x1800 resolution on a 13'
screen,
> > JMeter
> > > is
> > > >>>>>
> > > >>>> very
> > > >>>>
> > > >>>>> small with the CrossPlatform Swing UI)
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On 03/01/2016 15:08, Philippe Mouawad wrote:
> > > >>>>>
> > > >>>>>> Hi Felix,
> > > >>>>>> Thanks for answer.
> > > >>>>>> I don't think it will be a long hold on the new release,
for me
> we
> > > >>>>>> have
> > > >>>>>> these remaining points:
> > > >>>>>>
> > > >>>>>>      - Integrate HTTPCLIENT 4.5.2 to fix
> > > >>>>>>      - 58583 <
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=58583>
> > > >>>>>>         - 57319
> > > >>>>>>      - Finalize tests
> > > >>>>>>      - 57804 => Waiting confirmation from Rainer
or any other
> > member
> > > >>>>>> of
> > > >>>>>>
> > > >>>>> the
> > > >>>>
> > > >>>>>         team
> > > >>>>>>         - Deprecation:
> > > >>>>>>         - 58791 => I will do it
> > > >>>>>>         - Not mandatory but would be nice:
> > > >>>>>>         - 58793
> > > >>>>>>         - 58790
> > > >>>>>>         - 58792 => I will try to stat it
> > > >>>>>>         - 58794 => I will start a discussion on
this
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> That's all for me, but if you see other things feel
free to add
> > it.
> > > >>>>>>
> > > >>>>>> Thanks
> > > >>>>>>
> > > >>>>>> Regards
> > > >>>>>>
> > > >>>>>> Philippe M.
> > > >>>>>>
> > > >>>>>> @philmdot
> > > >>>>>>
> > > >>>>>> On Sun, Jan 3, 2016 at 3:37 PM, Felix Schumacher <
> > > >>>>>> felix.schumacher@internetallee.de> wrote:
> > > >>>>>>
> > > >>>>>> Am 01.01.2016 um 19:14 schrieb Philippe Mouawad:
> > > >>>>>>>
> > > >>>>>>> Hi,
> > > >>>>>>>> Happy new year to the whole team.
> > > >>>>>>>>
> > > >>>>>>>> Any news on this ?
> > > >>>>>>>>
> > > >>>>>>>> I have nothing against a 3.0, but I would
not like it, if the
> > > "big"
> > > >>>>>>> version change would lead to a long hold up of
a new release.
> > > >>>>>>>
> > > >>>>>>> Regards,
> > > >>>>>>>    Felix
> > > >>>>>>>
> > > >>>>>>> Thanks
> > > >>>>>>>
> > > >>>>>>>> On Tue, Dec 29, 2015 at 5:19 PM, Philippe
Mouawad <
> > > >>>>>>>> philippe.mouawad@gmail.com> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Hi,
> > > >>>>>>>>
> > > >>>>>>>>> Following my proposals to deprecate a
certain number of
> > elements
> > > >>>>>>>>> that
> > > >>>>>>>>> were
> > > >>>>>>>>> approved by 2 commiters and knowing that
we have some
> important
> > > new
> > > >>>>>>>>> features in this release, I propose to
name next version 3.0
> > > >>>>>>>>> instead
> > > >>>>>>>>>
> > > >>>>>>>> of
> > > >>>>
> > > >>>>> 2.14.
> > > >>>>>>>>> It would be the occasion to make a big
cleanup in all
> "oldies"
> > > >>>>>>>>>
> > > >>>>>>>> elements
> > > >>>>
> > > >>>>> and maybe be even more aggressive in the deprecations/removals.
> > > >>>>>>>>>
> > > >>>>>>>>> And starting from there change our release
naming to follow
> > this:
> > > >>>>>>>>> - http://semver.org/
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> This has been mentioned by this thread
and I think it's a
> good
> > > >>>>>>>>> idea:
> > > >>>>>>>>> -
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201411.mbox/%3CCAFJ7uesG%2BsKiQh_wQ5_iLp%3DJ%2BtSiG5fQ%3D7Pp1CvbJ1kncXo%2B%3Dg%40mail.gmail.com%3E
> > > >>>>
> > > >>>>> I think in the developers thinking our current naming
is not
> great,
> > > >>>>>>>>> cause
> > > >>>>>>>>> one can think every "major" release we
do is a Minor release.
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Regards
> > > >>>>>>>>> Philippe M.
> > > >>>>>>>>> @philmdot
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>
> > > >>> --
> > > >>> Cordialement.
> > > >>> Philippe Mouawad.
> > > >>>
> > > >> .
> > > >>
> > > >>
> > > >
> > >
> >
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>



-- 
Cordialement.
Philippe Mouawad.

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