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 Wed, 20 Jan 2016 20:43:02 GMT
Hi,
Pinging again on this.
Regards

On Thu, Jan 14, 2016 at 3:16 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

> 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.
>
>
>


-- 
Cordialement.
Philippe Mouawad.

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