jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gomes Rodrigues <ra0...@gmail.com>
Subject Re: Release a 3.0
Date Wed, 13 Jan 2016 16:28:15 GMT
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 <milamber@apache.org>:

> Hello,
>
> For me, the jump to 3.0 must be done for next version.
>
>
> Remember: JMeter 2.0.0 was release in 2004, so 12 years ago and 23
> versions have been release since!
>
> A lot of works since 2004 on the user interface (the toolbar, sampler
> forms, graphical listener, etc.)
>
> A lot of works under the woods, to improve the JMeter internal
> performance, the samplers like HTTP request (default HC4), the parallel
> resource download, etc)
>
> A lot of works to improve the user experience (like the Regexp tester, the
> templates box, the search on the JMeter tree, log pane, OS integration for
> copy/paste, POST body for WS request, etc.)
>
> Recently, a lot of works on the website to refresh the design (and logo)
> (a lot of this changes will publish on the next release)
>
> IMHO, the bump to JMeter 3.0, exceptionally can not only based on the new
> behaviors since the previous version (N-1) or API changes, but we need to
> consider the works of all developers since 2004. (and after change to a new
> number rules)
>
>
> Apache JMeter isn't comparable with project like Commons or HTTPClient on
> the versions rules. Commons/HC are mainly use as a framework inside another
> software (like JMeter). JMeter is mainly use a as end user software, the
> API (break/don't break) isn't the alone criteria to change the versions
> number. The UI and the engine must be consider to the next release number.
>
> Last reason to change : The users may be confused with a 2.x version from
> 2004 (works only with Java 1.4, some jvm args are now incompatibles) and a
> 2.14 version which require Java 7.
>
>
> Milamber
>
>
>
>
>
> On 05/01/2016 11:01, sebb wrote:
>
>> On 4 January 2016 at 18:23, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>>
>>> First Happy new year 2016 !
>>>
>>>
>>>
>>> On Mon, Jan 4, 2016 at 4:26 PM, sebb <sebbaz@gmail.com> wrote:
>>>
>>> JMeter does not have a formal policy for major/minor version release
>>>> updates.
>>>> However historically major veresion changes have been associated with
>>>> major changes.
>>>>
>>>> I am proposing to follow what seems to become a standard in versioning
>>> refering to a proposal from a scientist working on the subject.
>>>
>> http://semver.org/ says:
>>
>> Increment the MAJOR version when you make incompatible API changes,
>>
>> We are not doing that.
>>
>> Also other ASF projects such as Commons and HttpClient require major
>>>> version bumps when removing deprecated code.
>>>>
>>>> So isn't this what we are doing as we dropped 4 classes corresponding to
>>> deprecated elements. And we will deprecate some more.
>>> But the main idea behind this is that next version contains major
>>> features
>>> which I think deserve this change.
>>>
>> What features are you referring to?
>>
>>
>>> I don't think the proposed changes warrant a major version bump.
>>>>
>>>> I don't understand, but if we don't come to an agreement I propose to
>>> run a
>>> vote on this although it would be better to avoid it.
>>>
>>> On 3 January 2016 at 15:36, Milamber <milamber@apache.org> wrote:
>>>>
>>>>> I agree with a new release with a new version number system, and with
>>>>> the
>>>>> next release to become 3.0.
>>>>>
>>>>> Before the next release, I would like add the HiDPI (high definition
>>>>>
>>>> screen)
>>>>
>>>>> for JMeter (for Linux Gnome/GTK and Windows). Currently I works on
>>>>> this.
>>>>> (my new computer have a 3200x1800 resolution on a 13' screen, JMeter
is
>>>>>
>>>> very
>>>>
>>>>> small with the CrossPlatform Swing UI)
>>>>>
>>>>>
>>>>>
>>>>> On 03/01/2016 15:08, Philippe Mouawad wrote:
>>>>>
>>>>>> Hi Felix,
>>>>>> Thanks for answer.
>>>>>> I don't think it will be a long hold on the new release, for me we
>>>>>> have
>>>>>> these remaining points:
>>>>>>
>>>>>>      - Integrate HTTPCLIENT 4.5.2 to fix
>>>>>>      - 58583 <https://bz.apache.org/bugzilla/show_bug.cgi?id=58583>
>>>>>>         - 57319
>>>>>>      - Finalize tests
>>>>>>      - 57804 => Waiting confirmation from Rainer or any other
member
>>>>>> of
>>>>>>
>>>>> the
>>>>
>>>>>         team
>>>>>>         - Deprecation:
>>>>>>         - 58791 => I will do it
>>>>>>         - Not mandatory but would be nice:
>>>>>>         - 58793
>>>>>>         - 58790
>>>>>>         - 58792 => I will try to stat it
>>>>>>         - 58794 => I will start a discussion on this
>>>>>>
>>>>>>
>>>>>> That's all for me, but if you see other things feel free to add it.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Philippe M.
>>>>>>
>>>>>> @philmdot
>>>>>>
>>>>>> On Sun, Jan 3, 2016 at 3:37 PM, Felix Schumacher <
>>>>>> felix.schumacher@internetallee.de> wrote:
>>>>>>
>>>>>> Am 01.01.2016 um 19:14 schrieb Philippe Mouawad:
>>>>>>>
>>>>>>> Hi,
>>>>>>>> Happy new year to the whole team.
>>>>>>>>
>>>>>>>> Any news on this ?
>>>>>>>>
>>>>>>>> I have nothing against a 3.0, but I would not like it, if
the "big"
>>>>>>> version change would lead to a long hold up of a new release.
>>>>>>>
>>>>>>> Regards,
>>>>>>>    Felix
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>> On Tue, Dec 29, 2015 at 5:19 PM, Philippe Mouawad <
>>>>>>>> philippe.mouawad@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> Following my proposals to deprecate a certain number
of elements
>>>>>>>>> that
>>>>>>>>> were
>>>>>>>>> approved by 2 commiters and knowing that we have some
important new
>>>>>>>>> features in this release, I propose to name next version
3.0
>>>>>>>>> instead
>>>>>>>>>
>>>>>>>> of
>>>>
>>>>> 2.14.
>>>>>>>>> It would be the occasion to make a big cleanup in all
"oldies"
>>>>>>>>>
>>>>>>>> elements
>>>>
>>>>> and maybe be even more aggressive in the deprecations/removals.
>>>>>>>>>
>>>>>>>>> And starting from there change our release naming to
follow this:
>>>>>>>>> - http://semver.org/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This has been mentioned by this thread and I think it's
a good
>>>>>>>>> idea:
>>>>>>>>> -
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> http://mail-archives.apache.org/mod_mbox/jmeter-dev/201411.mbox/%3CCAFJ7uesG%2BsKiQh_wQ5_iLp%3DJ%2BtSiG5fQ%3D7Pp1CvbJ1kncXo%2B%3Dg%40mail.gmail.com%3E
>>>>
>>>>> I think in the developers thinking our current naming is not great,
>>>>>>>>> cause
>>>>>>>>> one can think every "major" release we do is a Minor
release.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Regards
>>>>>>>>> Philippe M.
>>>>>>>>> @philmdot
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>
>>> --
>>> Cordialement.
>>> Philippe Mouawad.
>>>
>> .
>>
>>
>

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