Re: [Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)
+1 for something like this. Its not a huge problem not to do semver but it'd be simpler to explain if we did. On Sun, Jan 25, 2015 at 10:27 AM, Legoktm legoktm.wikipe...@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, let's do this. It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)
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, let's do this. It would allow us to follow semver and still retain our current version number history instead of waiting for a magical 2.0. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core (was: Re: Fwd: No more Architecture Committee?)
On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core
On 01/25/2015 06:04 PM, Zack Weinberg wrote: On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@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. Except that every 1.x release *does* contain breaking changes. If we followed semver we would be bumping the major version, but we don't. -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sane versioning for core
On 2015-01-25 6:04 PM, Zack Weinberg wrote: On Sun, Jan 25, 2015 at 1:27 PM, Legoktm legoktm.wikipe...@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) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
