Re: [SMW-devel] Making SMW semver.org compliant

2014-01-16 Thread Jeroen De Dauw
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

Re: [SMW-devel] Making SMW semver.org compliant

2014-01-16 Thread Yury Katkov
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

Re: [SMW-devel] Making SMW semver.org compliant

2014-01-16 Thread Jeroen De Dauw
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

Re: [SMW-devel] Making SMW semver.org compliant

2014-01-16 Thread Yaron Koren
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

[SMW-devel] Making SMW semver.org compliant

2014-01-16 Thread Jeroen De Dauw
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