-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org/
iEYEARECAAYFAk9OUzcACgkQAXWvBxzBrDAbXACeMGwqiBxaI53ZWqfyjM23mJzx
Cr4AoJcw67SqGmO6tyF3GjDZBNIF0HrN
=BoAV
-----END PGP SIGNATURE-----
