jmeter-dev mailing list archives

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



-- 
Thank you,

Regards,
NaveenKumar N
Visit www.QAInsights.com and www.Testifications.com and www.MyTechCube.com

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