Topic on Extension talk:TemplateData

I can neither prove nor disprove this edit. Could someone check it, please? Tim (SVG) 08:15, 17 February 2014 (UTC)

I, also, wondered about this edit when I saw it. I was not involved with any earlier version. Thus, I can not state from past experience as to TemplateData being available for 1.20 (what the text was changed from). However, I was able to determine some information:

1. TemplateData is downloadable for 1.21.
2. All changes for TemplateData I looked at within en.wiki indicated that such changes started in late June 2013. This corresponds with when the 1.21 release would have gone live on enwiki.

I can not prove that it is available for 1.20, but it definitely is available for 1.21. I have changed the text accordingly.

You may be confused. The infobox information is about the latest code. Of course one can always dig the past, but it's another matter.

In part, yes, I was not using the correct definitions. Frankly, I should have looked at the source code to begin with.

However, I have now looked at the actual code (from download) that is available for MediaWiki 1.21 and 1.22. Both versions of the code downloaded claim to be TemplateData version 0.1.0. The download for MW 1.21 claims that it requires at a minimum MediaWiki version of 1.20. The download for MediaWiki 1.22 states that it requires MW 1.22wmf18.

However, there appears to be a significant issue. The code, not just translations, changed substantially between the version provided with MW 1.21 and that provided with MW 1.22, but the version number of the TemplateData code was not changed.

The version downloadable for MW 1.21 contains:
364 lines of code
153 lines specifying the TemplateData JSON
44 lines of language localization
0 lines of tests

The version downloadable for MW 1.22 contains:
918 lines of code
108 lines specifying the TemplateData JSON
1009 lines of language localization
621 lines of tests

Discounting the changes to the TemplateData JSON spec, the translations, and existence of tests, that is more than 2.5 times as many lines of code in the version released with MW 1.22 as that released with MW 1.21, yet the TemplateData version number on both is 0.1.0. Admittedly, some of those changes are just re-formatting. But there are real, substantial changes in there.

I'm new to even looking at MediaWiki code, but there is no situation that I have seen where this much change in the actual code (discounting translations and tests) does not justify at least some change in the version level of the code. There is a lot of functionality in there now that was not in there in the code released with MW 1.21. In most situations I have seen if the code changes after a release, the version number is changed, even if it is a very minor change in the code. What I have normally seen is: the code is different from what was released in any way → it gets a new version number. Adding tests, and translations doesn't necessarily require a change in version number, but these are some significant functional changes.

Just to check, I have also glanced at the latest development version. The current master version:
1077 lines of code
120 lines specifying the TemplateData JSON
2032 lines of language localization
829 lines of tests
The TemplateData version number is still 0.1.0

Given that all of them claim to be version 0.1.0, and the earliest claims compatibility with MW 1.20, I have changed the infobox back to 1.20, which is where it was prior to any recent changes. It should be noted that the date on the "current version" is also inaccurate. The date on the code provided for MW 1.21 is 2013-03-15. The date on the code for MW 1.22 is 2013-10-22. Given that the TemplateData revision number is the same for all of the versions, I am not going to change the date in the infobox from its current value of 2013-05-16. This is more me saying that the issue needs to be addressed by someone closer to the development than anything else.

Version numbers don't mean absolutely anything in MediaWiki extensions. I've not reviewed all you've written above, but if you made an assumption of the contrary you may need to revisit them.

Ok. I must admit that I am surprised no, stunned that version numbers are used and then expected to mean nothing. It would be far better not to use them at all than to use them and have them mean nothing. Version numbers are used throughout the technology sector to track changes to almost everything. They exist and developed due to a need to be able to track changes with a single, easily understood, indicator; so that people did not need to be intimately involved to determine if two things were identical. Version numbers are a normal, and expected part of almost everything technological, particularly software. So much so that even a layman knows that version 3.1.5 is earlier than, and different from, version 3.1.8. Even a layman expects that if he has version 3.1.5 and another person has version 3.1.5 then they have exactly the same thing. By using version numbers and then having them mean nothing you are setting up your users to have false expectations.

I know that the software is in a Git repository; that the developers can trivially see when files have been committed and are different. Your "customers" should not be expected to go to have to go to that level to tell that 0.1.0 is not identical to version 0.1.0. They certainly do not come to the project expecting to need to do so.

Seriously, is there any valid reason that such version numbers are not kept valid (i.e. changed when changes in the code are made after a release). It is trivial to change the version number from "0.1.0" to "0.1.1" upon making changes to the source code. Is there somewhere that explains why this is not done? Or explains at all that it is something not to be expected here?

I am not trying to pick on this particular extension, you, or anyone specifically, it is just that an attitude of "version numbers mean nothing" – which I am assuming is a general case, not specific to you or this extension – is just so fundamentally contrary to my expectations, and I believe the expectations of the vast majority of people not steeped in the development here, that I am having a hard time seeing how or why it would come to be the case.

The reason is simple: there isn't any release system for extensions, hence version/release numbers don't really affect anything.

Than why isn't it just version 0.0 forever? At least that looks bogus ...

Version 0.1.0 looks just as bogus and doesn't cause breakage in version management tools, hence why it's the standard for this kind of situation.

0.1.0 doesn't look particularly bogus on the face of things.

As such, it is a bad version number to use as a bogus placeholder.

Makyen's rant explains the issues in more detail, and also explains why TemplateData in particular should have version numbers.

Your "customers" should not be expected to go to have to go to that level to tell that 0.1.0 is not identical to version 0.1.0. They certainly do not come to the project expecting to need to do so.

This is code in active development to meet support criteria that shift from day-to-day in VisualEditor (and other potential users). "0.1.0" is a standard flag for "very early code, don't expect things to continue to be similar, don't build off this". I'm sorry that this semantic meaning eluded you. Arguably I shouldn't have changed the "status" from "experimental" to "beta", but it's not ready for third party dependency development.

I agree 100% with using everything in Semantic Versioning 2.0.0. It is completely consistent with what I was attempting convey, and my expectations. The problem is that Extension:TemplateData is not using it. Version 0.1.0 is where you start. It is not where you leave it. To quote that page:

"3. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version."

Versions, by definition, have been released. Whether it was desirable/intended or not, by having versions available via the ExtensionDistributor those are absolutely releases. If someone does not need to use Git to obtain the code, that is certainly a release. Further, those releases have been used in major areas (enwiki). Actually, when dealing with inter-project dependencies it is appropriate for the revision to roll even when one still has to use Git to obtain the code. Version numbers are usually used to track changes to code and are rolled when changes are released to view by people outside the specific sub-project. From the view of a sub-project the "public", to determine if it is a "release", is usually considered to any general view-ability by people outside the specific sub-project.

I really don't see why there would be resistance to rolling the version from 0.1.0 to 0.1.1 or 0.2.0, or as appropriate, when things change after each release. These are still clear and obvious development versions. To quote Semantic Versioning 2.0.0:

"4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable."

Keeping the version at 0.1.0 is only reasonable prior to having the code in use for anything other than initial development by only those specifically working on the Extension:TemplateData code alone, without releasing it into any wider use (i.e. not released for use by VisualEditor). The 0.1.0 version level is effectively for code that is at a level of "I have just started work on this and not made it available to anyone else yet." Rolling version numbers is normal. You have the whole infinite set of integers to work with. There is no reason not to use them.

You state that it is in active development to meet the criteria of one, or more, non-TemplateData projects (VisualEditor is provided as an example). That is all the more reason to actually use Semantic Versioning 2.0.0. You have given an example of exactly why it is important to use versioning: so that those interfacing with the code, who are outside of the specific TemplateData project, know what version they are running against. That it is in development to meet the needs of another project is not an argument for keeping the version at 0.1.0, it is an argument for actually using versioning as described in Semantic Versioning 2.0.0. The API is being used by another project. That, by definition, means the API is public, not private (i.e. being used only in the TemplateData project).

Just to be clear: I am only here because I am writing code which is using the JSON data provided by TemplateData. I am using data supplied by the released versions which have been running on enwiki for 8 months. There is a public API. It is defined at least at: Extension:TemplateData, here (because it is referenced on the extension page), and here. I would not be here if the TemplateData API was not already public, because I would not have been able to find it, or use it. It was public at least by 10 June 2013 when it was described on Extension:TemplateData. By the end of that month it was publicly released to millions of people by its use on enwiki, and elsewhere.

From your comments here it appears that the unstated reason you are objecting to rolling the version number is that you have not "released" the code. The reality is that the code was released months ago. It does not matter that you do not desire to consider it "released". The fact that it is available from ExtensionDistributor by definition means that it has been publicly released not just once, but twice. Further, I would say that anything that is loaded onto enwiki is certainly released. Actually, under most development situations a "release" for a sub-project is when the code is made available for use by other sub-projects, not just when it is made available to the public at large, or when the overall project is released to the general public.

I really don't understand why there is resistance to rolling the revision number to a higher 0.y.z version. Version numbers are not a finite resource that can be used up. Versions are not something that should be horded. They, the 0.y.z revisions, should be rolled freely when changes occur, as described in Semantic Versioning 2.0.0. Keeping the version at 0.1.0 is completely contrary to the concepts and reasoning at Semantic Versioning 2.0.0.

I have deleted the false branches for REL1_21 (5abfff9f0a199193b3cf422984c355e3e9bb65c8) and REL1_22 (4c848ea297ee1c05c7f3805a224235a8000e096b) to avoid this issue in the future; thank you for flagging it.

These downloads have been automatically created, and misleadingly-so; I've fixed the infobox to be slightly clearer.

Ok.

From the very brief time I have been looking into MW software, that page appears to be a primary distribution method for extensions. It is where Manual:Extensions directs people to go to get extensions. It is reasonable that the downloads are automatically created, it is not reasonable that they be misleading. In what way are they misleading? Are they not the extension as it should be used with a specific version of MW?

From the very brief time I have been looking into MW software, that page appears to be a primary distribution method for extensions. It is where Manual:Extensions directs people to go to get extensions.

Indeed, and for boring extensions that haven't changed significantly in years it's fine, if a little dangerous.

It is reasonable that the downloads are automatically created, it is not reasonable that they be misleading. In what way are they misleading?

In-early-development code should not be branched automatically in a way that is advertised to users that the code is in a very high rate of change and is likely to break often.

Are they not the extension as it should be used with a specific version of MW?

No. They are the extension as it was when that specific version of MediaWiki was branched, according to a script that has no idea about the various statuses of the extensions it's branching.