You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2016/01/01 19:14:33 UTC
Re: Release a 3.0
Hi,
Happy new year to the whole team.
Any news on this ?
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.
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ph...@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 <mi...@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 <se...@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 <mi...@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.
Re: Release a 3.0
Posted by NaveenKumar Namachivayam <ca...@gmail.com>.
+1 for 3.0
On Mon, Feb 8, 2016 at 5:58 AM, Philippe Mouawad <philippe.mouawad@gmail.com
> wrote:
> Hello,
> Status for now:
>
> For a 3.0:
>
> - Milamber (*)
> - Antonio Gomes Rodrigues
> - me (*)
>
> For a 2.14:
>
> - sebb (*)
>
> For a 3.0 if it does not holds next release for too long (this is not the
> case, for now release 3.0 is blocked by release of HttpClient 4.5.2 and
> this discussion):
>
> - Felix (*)
>
> (*) Binding as PMC member
>
>
> Do I need to open a technical vote on this issue or can we go for a 3.0.0 ?
>
> I will wait 24 hours before starting this technical vote.
>
>
> Regards
>
> Philippe
>
> On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
> > Hi,
> > If this is to block next release, then I will go for a 2.14 although I
> > think that this numbering makes people think JMeter is only releasing
> minor
> > fixes and think they don't have to upgrade.
> >
> > Please sebb, can you give your final thought ?
> > thankd
> >
> > Regards
> > Philippe
> >
> >
> > On Monday, January 25, 2016, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> > wrote:
> >
> >> 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 <se...@gmail.com> wrote:
> >>
> >>> On 24 January 2016 at 11:30, Felix Schumacher
> >>> <fe...@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
> >>> >> <ra...@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 <mi...@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 <se...@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 <mi...@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.
> >
> >
> >
> >
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
--
Thank you,
Regards,
NaveenKumar N
Visit www.QAInsights.com and www.Testifications.com and www.MyTechCube.com
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tue, Feb 9, 2016 at 8:01 PM, sebb <se...@gmail.com> wrote:
> On 8 February 2016 at 11:58, Philippe Mouawad
> <ph...@gmail.com> wrote:
> > Hello,
> > Status for now:
> >
> > For a 3.0:
> >
> > - Milamber (*)
> > - Antonio Gomes Rodrigues
> > - me (*)
> >
> > For a 2.14:
> >
> > - sebb (*)
> >
> > For a 3.0 if it does not holds next release for too long (this is not the
> > case, for now release 3.0 is blocked by release of HttpClient 4.5.2 and
> > this discussion):
> >
> > - Felix (*)
> >
> > (*) Binding as PMC member
> >
> >
> > Do I need to open a technical vote on this issue or can we go for a
> 3.0.0 ?
> >
> > I will wait 24 hours before starting this technical vote.
> >
>
> It's not clear to me what you are asking here.
>
> Are you asking:
> - if the next version should be 3.0 rather than 2.14?
>
Yes
> or
> - are we ready to release 3.0?
>
No
>
> As to the former, I still think it's unnecessary to bump to 3.0.
> There are some disadvantages, as a major version bump implies
> potentially major upheavals or even breakages (think of certain OS
> system version bumps).
> However since the version discussion started there have been quite a
> few more improvements, and there are some minor incompatibilities, so
> I will abstain on this question.
>
Thanks
>
> As to are we ready, I don't think we are there quite yet.
> The new dashboard still needs some work.
>
I see you are creating bugzillas now. Ok for me
> There are issues with the new version of HC.
>
Yes anyway, we are still waiting for 4.5.2 release. As you are a HTTPClient
commiter and PMC member, do you know when a release is planned ?
As of remaining issues, as far as I can tell , here are the remaining
issues:
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58807
<https://bz.apache.org/bugzilla/show_bug.cgi?id=58807> => Patch available ,
waiting for commit
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58583
<https://bz.apache.org/bugzilla/show_bug.cgi?id=58583> => Just Needs
HC4.5.2+ Uncomment code
- https://bz.apache.org/bugzilla/show_bug.cgi?id=57804 => Waiting for
Rainer confirmation + my comment to check:
------------------------------------------------------------------------------------------------------------------------------------------------
Beside this, I notice a change in the logs in the NoClientCert test case
attached between 2.13 and 2.14, I cannot tell if it's a bug or regular.
If you compare nohup-2.14-pre-commit-1721771-no-client-cert.log with
nohup-2.13-no-client-cert.log.
With 2.13 I see only 1 time => *** ClientHello, TLSv1
With 2.14 I see 4 times => *** ClientHello, TLSv1, but preceded the 3 last
times with => %% Try resuming [Session-1,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA] from port 2571
------------------------------------------------------------------------------------------------------------------------------------------------
- Ignore policy in Cookie => Just needs HC4.5.2
- https://bz.apache.org/bugzilla/show_bug.cgi?id=58950 => Just Needs
HC4.5.2 and potentially there is another issue
<https://bz.apache.org/bugzilla/show_bug.cgi?id=58950>
Do you see anything else ?
> > Regards
> >
> > Philippe
> >
> > On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad <
> > philippe.mouawad@gmail.com> wrote:
> >
> >> Hi,
> >> If this is to block next release, then I will go for a 2.14 although I
> >> think that this numbering makes people think JMeter is only releasing
> minor
> >> fixes and think they don't have to upgrade.
> >>
> >> Please sebb, can you give your final thought ?
> >> thankd
> >>
> >> Regards
> >> Philippe
> >>
> >>
> >> On Monday, January 25, 2016, Philippe Mouawad <
> philippe.mouawad@gmail.com>
> >> wrote:
> >>
> >>> 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 <se...@gmail.com> wrote:
> >>>
> >>>> On 24 January 2016 at 11:30, Felix Schumacher
> >>>> <fe...@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
> >>>> >> <ra...@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 <mi...@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 <se...@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 <mi...@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.
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
>
--
Cordialement.
Philippe Mouawad.
Re: Release a 3.0
Posted by sebb <se...@gmail.com>.
On 8 February 2016 at 11:58, Philippe Mouawad
<ph...@gmail.com> wrote:
> Hello,
> Status for now:
>
> For a 3.0:
>
> - Milamber (*)
> - Antonio Gomes Rodrigues
> - me (*)
>
> For a 2.14:
>
> - sebb (*)
>
> For a 3.0 if it does not holds next release for too long (this is not the
> case, for now release 3.0 is blocked by release of HttpClient 4.5.2 and
> this discussion):
>
> - Felix (*)
>
> (*) Binding as PMC member
>
>
> Do I need to open a technical vote on this issue or can we go for a 3.0.0 ?
>
> I will wait 24 hours before starting this technical vote.
>
It's not clear to me what you are asking here.
Are you asking:
- if the next version should be 3.0 rather than 2.14?
or
- are we ready to release 3.0?
As to the former, I still think it's unnecessary to bump to 3.0.
There are some disadvantages, as a major version bump implies
potentially major upheavals or even breakages (think of certain OS
system version bumps).
However since the version discussion started there have been quite a
few more improvements, and there are some minor incompatibilities, so
I will abstain on this question.
As to are we ready, I don't think we are there quite yet.
The new dashboard still needs some work.
There are issues with the new version of HC.
> Regards
>
> Philippe
>
> On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>> Hi,
>> If this is to block next release, then I will go for a 2.14 although I
>> think that this numbering makes people think JMeter is only releasing minor
>> fixes and think they don't have to upgrade.
>>
>> Please sebb, can you give your final thought ?
>> thankd
>>
>> Regards
>> Philippe
>>
>>
>> On Monday, January 25, 2016, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>>
>>> 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 <se...@gmail.com> wrote:
>>>
>>>> On 24 January 2016 at 11:30, Felix Schumacher
>>>> <fe...@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
>>>> >> <ra...@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 <mi...@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 <se...@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 <mi...@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.
>>
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
Status for now:
For a 3.0:
- Milamber (*)
- Antonio Gomes Rodrigues
- me (*)
For a 2.14:
- sebb (*)
For a 3.0 if it does not holds next release for too long (this is not the
case, for now release 3.0 is blocked by release of HttpClient 4.5.2 and
this discussion):
- Felix (*)
(*) Binding as PMC member
Do I need to open a technical vote on this issue or can we go for a 3.0.0 ?
I will wait 24 hours before starting this technical vote.
Regards
Philippe
On Tue, Feb 2, 2016 at 11:48 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
> Hi,
> If this is to block next release, then I will go for a 2.14 although I
> think that this numbering makes people think JMeter is only releasing minor
> fixes and think they don't have to upgrade.
>
> Please sebb, can you give your final thought ?
> thankd
>
> Regards
> Philippe
>
>
> On Monday, January 25, 2016, Philippe Mouawad <ph...@gmail.com>
> wrote:
>
>> 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 <se...@gmail.com> wrote:
>>
>>> On 24 January 2016 at 11:30, Felix Schumacher
>>> <fe...@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
>>> >> <ra...@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 <mi...@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 <se...@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 <mi...@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.
>
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
Hi,
If this is to block next release, then I will go for a 2.14 although I
think that this numbering makes people think JMeter is only releasing minor
fixes and think they don't have to upgrade.
Please sebb, can you give your final thought ?
thankd
Regards
Philippe
On Monday, January 25, 2016, Philippe Mouawad <ph...@gmail.com>
wrote:
> 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
> <javascript:_e(%7B%7D,'cvml','sebbaz@gmail.com');>> wrote:
>
>> On 24 January 2016 at 11:30, Felix Schumacher
>> <felix.schumacher@internetallee.de
>> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','ra0077@gmail.com');>>
>> >> wrote:
>> >>
>> >>> Hi
>> >>>
>> >>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <
>> philippe.mouawad@gmail.com
>> <javascript:_e(%7B%7D,'cvml','philippe.mouawad@gmail.com');>>:
>> >>>
>> >>>> On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues <
>> >>>
>> >>> ra0077@gmail.com <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','philippe.mouawad@gmail.com');>>
>> >>>>>>>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> First Happy new year 2016 !
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <sebbaz@gmail.com
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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.
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 24 January 2016 at 11:30, Felix Schumacher
> <fe...@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
> >> <ra...@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 <mi...@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 <se...@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 <mi...@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.
Re: Release a 3.0
Posted by sebb <se...@gmail.com>.
On 24 January 2016 at 11:30, Felix Schumacher
<fe...@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
>> <ra...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <ph...@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 <mi...@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 <se...@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 <mi...@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.
>>>>
>>
>>
>
Re: Release a 3.0
Posted by Felix Schumacher <fe...@internetallee.de>.
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.
Regards,
Felix
>
> Thanks
> Regards
>
> On Wed, Jan 13, 2016 at 10:18 PM, Antonio Gomes Rodrigues <ra...@gmail.com>
> wrote:
>
>> Hi
>>
>> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <ph...@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 <mi...@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 <se...@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 <mi...@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.
>>>
>
>
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ra...@gmail.com>
wrote:
> Hi
>
> 2016-01-13 21:43 GMT+01:00 Philippe Mouawad <ph...@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 <mi...@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 <se...@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 <mi...@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.
Re: Release a 3.0
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
Hi
2016-01-13 21:43 GMT+01:00 Philippe Mouawad <ph...@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 <mi...@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 <se...@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 <mi...@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.
>
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
On Wed, Jan 13, 2016 at 5:28 PM, Antonio Gomes Rodrigues <ra...@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 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 ?
>
> 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.
Anyway thanks for all those ideas.
>
> Antonio
>
>
>
>
>
>
> 2016-01-08 0:48 GMT+01:00 Milamber <mi...@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 <se...@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 <mi...@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.
Re: Release a 3.0
Posted by Antonio Gomes Rodrigues <ra...@gmail.com>.
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, Graph Results,Assertion Results)
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 think it will be great to separate the listener in two parts:
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)
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
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)
Antonio
2016-01-08 0:48 GMT+01:00 Milamber <mi...@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 <ph...@gmail.com>
>> wrote:
>>
>>> First Happy new year 2016 !
>>>
>>>
>>>
>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <se...@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 <mi...@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.
>>>
>> .
>>
>>
>
Re: Release a 3.0
Posted by Milamber <mi...@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 <ph...@gmail.com> wrote:
>> First Happy new year 2016 !
>>
>>
>>
>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <se...@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 <mi...@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.
> .
>
Re: Release a 3.0
Posted by sebb <se...@gmail.com>.
On 4 January 2016 at 18:23, Philippe Mouawad <ph...@gmail.com> wrote:
> First Happy new year 2016 !
>
>
>
> On Mon, Jan 4, 2016 at 4:26 PM, sebb <se...@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 <mi...@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.
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
First Happy new year 2016 !
On Mon, Jan 4, 2016 at 4:26 PM, sebb <se...@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.
> 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.
> 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 <mi...@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.
Re: Release a 3.0
Posted by sebb <se...@gmail.com>.
JMeter does not have a formal policy for major/minor version release updates.
However historically major veresion changes have been associated with
major changes.
Also other ASF projects such as Commons and HttpClient require major
version bumps when removing deprecated code.
I don't think the proposed changes warrant a major version bump.
On 3 January 2016 at 15:36, Milamber <mi...@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
>>>>>
>>>>>
>>>>>
>>
>
Re: Release a 3.0
Posted by Milamber <mi...@apache.org>.
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
>>>>
>>>>
>>>>
>
Re: Release a 3.0
Posted by Philippe Mouawad <ph...@gmail.com>.
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.
Re: Release a 3.0
Posted by Felix Schumacher <fe...@internetallee.de>.
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
>>
>>
>