jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JMeter version numbering
Date Mon, 29 May 2017 22:44:19 GMT
On 29 May 2017 at 22:48, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> On Monday, May 29, 2017, sebb <sebbaz@gmail.com> wrote:
>
>> On 29 May 2017 at 21:57, Philippe Mouawad <philippe.mouawad@gmail.com
>> <javascript:;>> wrote:
>> > Hello,
>> > I wonder if our versioning strategy is correct if we are supposed to
>> follow
>> > :
>> >
>> >    - http://semver.org/
>> >
>>
>> No, we do not have to follow that.
>> [AFAIK, it was not even in existence when JMeter started]
>>
>> It's up to individual projects to agree on what to versioning strategy to
>> use.
>>
>> Semantic versioning may or may not be suitable.
>
> it looks like a standard no ?
>

AFAIK it's just someone's idea of a strategy which they have documented.

It is fairly widely used, but I don't think it is a formal standard.

AFAICT it does not say anything about requiring a major version bump
if there is new functionality.
This seems to be something you are expecting, so it may not be suitable.

>
>>
>> But I agree the versioning strategy needs to be documented.
>
> yes
>
>>
>> > For example, 3.1 and 3.2 should maybe have been named 4.0.0 and 5.0.0
>> > because they both broke backward compatibility by deprecating/removing
>> > elements.
>>
>> Possibly.
>>
>> > Besides, in terms of communication, they were not minor at all.
>> > Maybe it's time to change this as if you have noticed it, I have read
>> > things like:
>> >
>> >    - This is the first major version of JMeter in over 12 years
>> >
>> > Which is kind of non sense for me knowing all the features that have been
>> > introduced in 2.X "minor" versions.
>>
>> Yes, it is nonsense.
>>
>> Note that major version bumps may be seen by some as negative.
>> There are lots of projects where a major bump always means
>> incompatible changes, with changes required to use them.
>
>
> probably , but I think we take special care of being able to read plans in
> older versions and document all changes and breaking ones.

Yes, JMeter has always strived to ensure that test plans are upwards compatible.

But that does not mean that people won't think that a major bump means
existing test plans will break.
I have seen that raised as an issue in the past.

>
>> The project should not base its versioning strategy on what 3rd parties
>> write.
>> It needs to decide the strategy independently, document it carefully,
>> and ensure it is adhered to going forward.
>
>
> I think it was unfortunately a rather common perception,  talking with
> other testers, they sometimes tell me they didn't find interest in
> upgrading as it was a minor version.

And others will say they are worried about upgrading to a new major
version because they think it may break compatibility.

> We cannot live isolated from what is written on project and need to either
> inform or take it into account.

The Release Notes and announcement email need to be very clear on the
consequences of upgrading or not.

>
>> > Regards
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message