-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
You may misunderstand me, this relies to starting the survey, not to deprecating any version! We have just started to talk about this. The survey page is the current proposal, and everybody will notice it when gets a nice colour warning on the screen. :-)
The survey page is for those who are not members of this list. We can directly talk about it here and that page is a help in our decision which should be made on this mailing list as the primary forum of developers. (My call for edit it aimed editing the mboxes on top.)
Yes, I definately missunderstood you! Good news for both of us! ;)
Well, I have never spoken about the actual date of ceasing support for old versions. When I told this two/few months I meant it as a time for reading opinions on survey page, making a decision and creating a roadmap. Possibly with different deadlines for old versions depending on number of users. The transitial time will begin then. Is that OK like this? A key in user-config.py is useful for users who are annoyed by reading about the survey at each run. After we made our decison and published it on MW, we may write another warning that disregards this suppresssurvey key and it will be reasonable to leave permanently. (In the way as @deprecated does now.)
Having read your notes on toolserver, I think the warning should appear only for version < 2.7.1, and not for 2.7.1 itself as it is widely used (if we already know it has to remain, a survey is unneccessary).
That makes sense!! This way you can also propose the future change to 2.7.2 which is a need because of the unicode bug - but has to be delayed until - at least - the toolserver has switched. And we have a central and permanent page to explain how to use older versions (according to Xqt's idea to make a snapshot of the current version you also mentioned) and to do further changes of that kind in future (e.g. to py3 ;).
I think cleaner code is always a programmer's preference and not waste of time (read the quotation here https://www.mediawiki.org/wiki/User:Bin%C3%A1ris), but let's talk about it. What about the Python 2.3 stuff in wikipedia.py? Any unneccessary old rubbish will make debugging harder. You may persuade me to leave it untouched, but from the point the decision is made I would like to write new code freely, either it works in ancient versions or not. (My favourite topic is "this if A else that" which is very practical. The magic we do sometimes with 2-element lists indexed by a logical value is marvellous, but much harder to read and uses a reversed logic having 'False' branch before 'True'. Or why not use a dictionary compehension http://docs.python.org/whatsnew/2.7.html#python-3-1-features if appropriate?)
This is what i wanted to cover with the proposal of the "we keep it until it sucks" position. If you work with that code and feel it becomes more handy when converting to newer python; do that! If debugging improves change the code! ;) But do not start searching all the code for old snipplets to wipe them out explicetly. (since you could end up spending a lot of time to convert code very rarely used at all or else...)
I tell you my secret purpose: after disconnecting 2.4 and 2.5 modules from our space station, I would like to bring the code as close to 3.x as possible. Someday we will face the task to switch to 3.x (trunk is not likely to survive this) and we may make it easier if from now on we try to keep this in mind when coding.
Why "is trunk not likely to survive this"? I have to admitt (because lack of time and need of the new features) I did not really look into py3 at all until now. But as far as I know a conversion should not be that hard at all... It can be done step by step, first making the code run at least and then polish it up... Is there something I am not aware of?
I like Xqt's idea to make a snapshot of the current version ("current" means the time we will determine) that will run forever.
I like this too!
There are two reasons I am a bit averse to it: as far as I know it needs installing and I like the purity of trunk to simply copy it, and the last news I read on this list was that rewrite did not read XML dump that is very important for me, what about this? Sure, one day I will have to change, but here I don't speak about my personal needs -- as far as trunk is supported, its code management is our common interest.
Last I heard was there are feature in trunk that will never ever make it into rewrite - so I will never ever have to chance to switch... (which is a pitty)
Greetings DrTrigon