Am 29.05.2017 um 23:48 schrieb Philippe Mouawad:
On Monday, May 29, 2017, sebb <[email protected]> wrote:
On 29 May 2017 at 21:57, Philippe Mouawad <[email protected]
<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 ?
I would say semantiv versioning (semver) is a standard, but not the only
one.
If I remember it correctly, we had a discussion, whether we should
follow semver with our release numbers. I think we were OK with using
it, but could not really commit on what changes would be OK to make,
even if they would break backward compatibility, when the API was
thought of private.
On the other hand, JMeter has a wide user base and we should strife to
keep the tests as backward compatible as possible, regardless what
version scheme we are using.
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.
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.
We cannot live isolated from what is written on project and need to either
inform or take it into account.
I have seen coverage for all "major" minor versions (3.1 and 3.2) of the
3.x releases, so third parties seem to think they are important :)
I am happy with the release numbering scheme we have right now, which I
see as: Try to keep backwards compatibility (stronger in "public" apis,
than in "private" apis) and improve in small steps.
Regards,
Felix
Regards
--
Cordialement.
Philippe Mouawad.
