Last modified: 2012-04-11 21:08:49 UTC
We have just been surprised that ArrayExtension is being removed from 1.19 and instead Arrays shall be used. With a breaking change, introducing a new extension is a good idea for a gradual switchover. However, the switchover is made more difficult by no longer providing the old extension under 1.19 and not yet providing the new version under 1.18. To give people time to upgrade smoothly to the improved Arrays extension, in my opinion it would help to already include that extension in the 1.18 release.
Do we even know if trunk Arrays works with 1.18?
(In reply to comment #1) > Do we even know if trunk Arrays works with 1.18? As if so, I'll happily branch it to 1.18, but no point doing it if it's just going to cause more hassle
Apologies, I should have said this: yes, it seems to do so. "Seems" because we are using it only for a day now... But that goes a long way, so if anything does not work, it could be fixed.
Umm, Arrays 2.0 hos not even been declared final/stable yet, but I guess it wouldn't harm drawing a line here. In fact, I was going to test it with 1.19 first before declaring it final.
(In reply to comment #4) > Umm, Arrays 2.0 hos not even been declared final/stable yet, but I guess it > wouldn't harm drawing a line here. In fact, I was going to test it with 1.19 > first before declaring it final. I think some line has been drawn when ArrayExtension was removed from 1.19. This did lead us to the assumption that it is very close to stable. If it is not, ArrayExtension should remain in 1.19. I have no clear opinion, the discussion is only about giving people time to migrate their templates.
Actually, the version which has slipped in R1.18 is a very bad one, since r81676 has introduced some kind of breaking behavior in #arraydefine which was fixed again in r103703 r81673 (1.3.2) or r103716 (last version of 1.4 alpha) should be fine for 1.18. Arrays 2.0 isn't ready, just did some test yesterday and there still have things to be done in #arrayprint which potentially break stuff (without compatibility mode at least). Since r103716 is half way to 2.0, r81673 would make most sense probably. With that one, nothing should change for anybody who has been using ArrayExtension before. (In reply to comment #5) > I think some line has been drawn when ArrayExtension was removed from 1.19. The latest ArrayExtension (1.4 alpha) at that time was intended to become pretty much the same 2.0 will be, just without the renaming which was an idea which came up later. The array store per parser is changing a lot of code, so I wanted to sort out all the other things first and implement compatibility mode to be better able to compare the before/after effect within my test cases.
It seems the best solution then is to update the code in 1.18 to a stable version rebranch ArrayExtension to (r103716) for 1.18, and restore the ArrayExtension code in 1.19 (marking it as deprecated in favor of Array). It seems that the mediawiki version which provides both versions in parallel to allow transition would better be 1.19, correct?
Honestly, I don't understand the hassle about this, why not simply putting r81673 into 1.18 for now, and when 2.0 is ready, putting it there as well. No need for restoring ArrayExtension for 1.19 then. 2.0 will be final in a week or even a few days when I find the time. So no worry about 2.0 not being ready when 1.19 is going to be final.
I assumed that changing the name is due to breaking changes. That is what the documentation says: "We strongly recommend updating to Arrays 2.0 since its corrects a severe bug but at the same time breaks compatibility with earlier versions. Documentation of previous versions can be found at Extension:Arrays/archive." If it does break compatibility, wiki installation need a version in which both extensions are installed side-by-side to the testing can be done. If, as from what you write, the new extension is simply a newer version of the old one, then I would prefer not to have a new name. It is frustrating if an extension simply disappears into Nirvana. Daniel: Close the bug by either correcting the mediawiki documentation page, or by providing a means for mediawiki users to make the transition in some version.
Its more complicated than that. The note which was added on the page is more due to documentation issues. We have discussed the whole thing on the extensions discussion page http://www.mediawiki.org/wiki/Extension_talk:Arrays and People came to the conclusion that this would be the time for renaming it. 2.0 brings lots of breaking behavior, but I decided to add a compatibility mode. Keeping compatibility is rather complex though, I have tested various cases where I have ensured compatibility to pre 1.4alpha releases, there might be just some minor cases where compatibility with active compatibility mode might not be given. This will allow people to change their templates or just stick with the old behavior. For wikis new to Arrays extension, using it from 2.0 on or later, they will never be concerned with somewhat inconsistent, weird or just changed old behaviors since compatibility mode is deactivated since 2.0 (its active by default in 1.4alpha). So I would do both, updating the documentation at some point as well as moving 2.0 into 1.18 (if thats even possible)
Thanks very much for your explanations. We all appreciate your efforts with this extension and are looking forward to a stable version 2.0
Do we need to do anything for this bug now? Or can it be closed?
closing, outdated, at least we worked around it by creating mixed distributions. I would hope that at some point mediawiki would make it simpler for its users and allow to upgrade from distribution to distribution, including all the extensions that are included in it.
