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 Mon, 25 Jan 2016 21:48:30 GMT
Hello,
Regarding API Changes, I think the following changes are breaking API/Plans
(in the sense of JMeter):

   - In RandomTimer class, protected instance timer has been replaced by
   getTimer() protected method, this is related to Bug 58100
   <http://bz.apache.org/bugzilla/show_bug.cgi?id=58100>. This may impact
   3rd party plugins.
   - org.apache.jmeter.gui.util.ButtonPanel has been removed, if you use it
   in your 3rd party plugin or custom development ensure you update your code.
   See Bug 58687 <http://bz.apache.org/bugzilla/show_bug.cgi?id=58687>
   - WebService(SOAP) Request and HTML Parameter Mask which were deprecated
   in 2.13 version, have now been removed following our deprecation strategy
   - org.apache.jmeter.protocol.http.visualizers.RequestViewHTTP.getQueryMap
   signature has changed, if you use it ensure you update your code. See Bug
   58845 <http://bz.apache.org/bugzilla/show_bug.cgi?id=58845>


And switching to 3.0 would allow us to be more aggressive in some changes:

   - Since version 3.0, you can use Nashorn Engine (default javascript
   engine is Rhino) under Java8 for Elements that use Javascript Engine
   (__javaScript, IfController). If you want to use it, use property
   javascript.use_rhino=false, see Bug 58406
   <http://bz.apache.org/bugzilla/show_bug.cgi?id=58406>. Note in future
   versions, we will switch to Nashorn by default, so users are encouraged to
   report any issue related to broken code when using Nashorn instead of
   Rhino. => Switch to use_rhino=true


Even if we did similar changes in previous versions and did not respect the
versioning system, I think we should do it starting from now.

Regards

On Sun, Jan 24, 2016 at 1:38 PM, sebb <sebbaz@gmail.com> wrote:

> On 24 January 2016 at 11:30, Felix Schumacher
> <felix.schumacher@internetallee.de> wrote:
> > Am 14.01.2016 um 15:16 schrieb Philippe Mouawad:
> >>
> >> Hi all,
> >> Can we go for a 3.0 or do we need to discuss it more or eventually run a
> >> vote on this ?
> >
> > I think there are two discussions in this thread. The first one was about
> > using semver for our versioning scheme. That scheme seemed to be
> accepted by
> > everyone.
> >
> > The other point was about the release number.
> >
> > The reasons that were brought up for a version 3.0 where of two kinds.
> >
> >  1. marketing (making it clear, that the jmeter from today is quite
> > different from the jmeter from years ago.)
> >
> >  2. semver. Here it wasn't clear, whether the changes in jmeter from the
> > last version where sufficient to call for a major release.
> >
> > I have run jpapicmp (https://siom79.github.io/japicmp/) comparing the
> last
> > three releases (including the next) and the tool reported major api
> changes
> > in all of them. So while a 3.0 would be valid for semver, it would have
> been
> > for the last two versions, too.
> >
> > I am still OK with going for semver for the versioning, but we might
> have to
> > discuss how we want to measure the api changes, so that we don't need to
> > discuss version numbers in the future.
> >
> > I am OK with a 3.0 considering the output of japicmp showed breaking api
> > changes, which would result in a new major release number.
>
> Breaking API changes shown by japicmp have very little bearing on
> whether JMeter users are affected.
> JMeter users are only likely to be affected by behaviourial changes.
>
> Even plugin writers are unlikely to be affected by the majority of API
> changes shown by japicmp.
>
> For example, not all public classes and methods are intended for use
> by plugin writers.
>
> The output of a tool such as japicmp is not particularly useful
> witthout proper analysis of the results.
> This would be true even of low-level library jars, as classes often
> have to be made public or protected even though they are not intended
> as part of the public API.
>
> Sorry, but I'm not sure that the analysis is much use in the case of
> JMeter.
>
> > Regards,
> >  Felix
> >
> >
> >>
> >> 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