On 17/01/14 15:09, Yaron Koren wrote:
> Hi,
>
> Markus - are you suggesting retroactively referring to, say, version
> 1.5.1 as version 5.1 - with a corresponding change to all the
> documentation, etc.? Or just jumping straight from version 1.9 to
> version 10.0? I'm assuming the latter, but in ei
Hi,
Markus - are you suggesting retroactively referring to, say, version 1.5.1
as version 5.1 - with a corresponding change to all the documentation,
etc.? Or just jumping straight from version 1.9 to version 10.0? I'm
assuming the latter, but in either case that seems like a bad idea, that
will i
Hey,
> Markus:
> the next version should be 10.0.0
Good point. +1 to this.
> Alexander:
> It is also important to tag all extensions. This is very often not the
case yet...
At least for SMW you can be sure all future releases will be tagged, since
Composer essentially requires one to tag in ord
+1 for using the semver.org definitions. This is especially important in
managed (enterprise) IT environments (ITIL...) where major changes
triggers different processes. It is also important to tag all
extensions. This is very often not the case yet...
/Alexander
Am 17.01.2014 10:41, schrieb M
Hi,
+1 to dropping the initial "1." that will never ever change.
However, since the 1 was unchanged since we are out of beta, it seems to
me that we are currently treating the second number as our major
version. In other words, we are at version 9.0.1 and the next version
should be 10.0.0. Thi
Hey Yury,
In case of MINOR versions, people know no compatibility breaks where made.
This means all versions of MediaWiki and PHP that where supported before
are still supported. It also means that no features where removed from SMW,
and that existing ones where not modified in such a way that old
Hi everyone!
I find myself difficult to understand the notion of MAJOR in semver.org :
> MAJOR version when you make incompatible API changes
IMHO MAJOR version - is when the amount of new stable tested features
reach some threshold, or when some key characteristics of the software
become signif
Hey,
> increasing the version number to 2.0, 3.0 etc. if/when it makes sense to
do that.
The thing is that we have not been doing this. Some of our last major
releases contained big breaking changes (DataItems, SQLStore3, Composer,
etc), and we did not increment the primary number. I do not expec
Hi,
It sounds like your real question is, "Shouldn't we have changed to 2.0
already?" :) I don't know the answer to that, but I can't imagine anyone
would object to increasing the version number to 2.0, 3.0 etc. if/when it
makes sense to do that.
(I don't think avoiding a 1.10, 1.11 etc. is by it
Hey,
I think it would be nice if SMW was http://semver.org/ compliant.
This means version numbers would look like MAJOR.MINOR.PATCH with a
possible stability suffix. This is very close to what we are already doing,
except that we are sticking a "1." in front of it. Having this shifted by
one migh
10 matches
Mail list logo
