On Sun, Jan 25, 2015 at 1:27 PM, Legoktm
<legoktm.wikipedia(a)gmail.com> wrote:
On 01/15/2015 08:26 PM, Chad wrote:
> I've been saying for over a year now we should just drop the 1. from
> the 1.x.y release versions. So the next release would be 25.0, 26.0,
> etc etc.
-1 from me, for what little that's worth...
It would allow us to follow semver and still
retain
our current version number history instead of waiting for a magical 2.0.
This
logic is the opposite of semver. Semver says you only bump the
major version number when you make a breaking change. Since breaking
changes are Bad Things, therefore bumping the major version number is
also a Bad Thing. It is something that you should strive to *avoid*
having to do.
Under semver, a version number of the form 1.<large integer> is a
*badge of honor*. It means that you have successfully executed many
releases *without* needing to make a breaking change. One should
display that initial 1. proudly; one should not consider it to be
superfluous.
zw
Whether fortunate or not 25.0, 26.0, etc... in reality is much closer to
semver than you think. We passed semver 1.x years ago.
Our releases are made over periods of 6 months or sometimes a whole
year. With this period nearly every one of our releases includes at
least one breaking change somewhere in the code. We even have a
dedicated breaking change section in the release notes.
Semver is a nice ideal. And for most libraries it works well, since they
have defined APIs and are explicitly intended to consumed by other
software and versions are directly used to control problems.
But MediaWiki is an application, and a large one at that. It's consumed
in a completely different way and if you were actually versioning it
there are actually multiple surfaces you would want to version which are
almost isolated from the actual release version number.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [