[lxml-dev] Lxml 1.0 will be released on Thursday, June 1st
Hallo everyone, just to keep us from pushing back release dates, Martijn and I have fixed the release date of lxml 1.0 to June 1st. The (long) list of changes for 1.0 is here: http://codespeak.net/svn/lxml/trunk/CHANGES.txt This means for you: If you want a bug-free release ready to install, then come and help us by testing the trunk and reporting any bugs you can find. http://codespeak.net/svn/lxml/trunk Build instructions are here: http://codespeak.net/lxml/build.html It also really helps us if you read the docs and report any difficulties you encounter. The in-development documentation is here: http://codespeak.net/svn/lxml/trunk/doc/ especially http://codespeak.net/svn/lxml/trunk/doc/api.txt http://codespeak.net/svn/lxml/trunk/doc/resolvers.txt and a little bit of http://codespeak.net/svn/lxml/trunk/doc/extensions.txt Any help is appreciated to make lxml 1.0 the best XML tool for Python - ever. :) Have fun, Stefan
Hello Stefan, Wednesday, May 17, 2006, 10:21:30 AM, you wrote: [...]
Any help is appreciated to make lxml 1.0 the best XML tool for Python - ever. Just let me know the day before and I'll provide the usual eggs. If you need anything else, please tell me, and I'll be happy in helping.
-- Best regards, Steve mailto:howe@carcass.dhs.org
Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> writes:
Hallo everyone,
just to keep us from pushing back release dates, Martijn and I have fixed the release date of lxml 1.0 to June 1st.
The (long) list of changes for 1.0 is here: http://codespeak.net/svn/lxml/trunk/CHANGES.txt
Does this include pretty printing? Is it possible not to strip the declaration? Or do I have to continue patching lxml for my use? Pretty printing makes XML readable and I don't want to develop any software that uses XML without it. -- Ilpo Nyyssönen # biny # /* :-) */
Hi Ilpo, Ilpo Nyyssönen wrote:
Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> writes:
just to keep us from pushing back release dates, Martijn and I have fixed the release date of lxml 1.0 to June 1st.
Does this include pretty printing?
No.
Is it possible not to strip the declaration?
If you mean what I think, then that's been fixed. If you mean something else, you may have to explain it.
Or do I have to continue patching lxml for my use?
Maybe, depending on why you patch it and how. This is open-source software. If you have a patch that adds a feature you need and have an interest in stopping to patch it yourself, you send a patch to the mailing list to have it included. Then we will discuss it and see if we can include it or what else we can do to add the missing feature. As long as we don't know what the missing feature is, we can't get it included. Stefan
Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> writes:
Does this include pretty printing? Is it possible not to strip the declaration?
[...]
Or do I have to continue patching lxml for my use?
Maybe, depending on why you patch it and how. This is open-source software. If you have a patch that adds a feature you need and have an interest in stopping to patch it yourself, you send a patch to the mailing list to have it included. Then we will discuss it and see if we can include it or what else we can do to add the missing feature.
Both of these were in a patch by someone else earlier, try google("lxml pretty print") for example. Of course that probably won't apply any more as is. -- Ilpo Nyyssönen # biny # /* :-) */
Stefan Behnel wrote:
Hallo everyone,
just to keep us from pushing back release dates, Martijn and I have fixed the release date of lxml 1.0 to June 1st.
The (long) list of changes for 1.0 is here: http://codespeak.net/svn/lxml/trunk/CHANGES.txt
This means for you:
If you want a bug-free release ready to install, then come and help us by testing the trunk and reporting any bugs you can find.
How about a 1.0beta release just to broaden the install base for this testing and bug hunting? Philipp
Ilpo Nyyssönen wrote:
Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> writes:
Does this include pretty printing? Is it possible not to strip the declaration? Or do I have to continue patching lxml for my use?
Maybe, depending on why you patch it and how. This is open-source software. If you have a patch that adds a feature you need and have an interest in stopping to patch it yourself, you send a patch to the mailing list to have it included. Then we will discuss it and see if we can include it or what else we can do to add the missing feature.
Both of these were in a patch by someone else earlier, try google("lxml pretty print") for example. Of course that probably won't apply any more as is.
I know about that patch, it was written by Geert Jansen resp. Patrick Wagstrom. And it will definitely not apply to 1.0. I rewrote the patch as simple as possible. The trunk now has support for the "pretty_print" keyword we discussed at that time. I preferred the keyword over a more general "XMLWriter" class approach, after Fredrik told me that ET 1.3 will have an "xml_declaration" keyword in the tostring function, so this is more consistent. Stefan
Hi Philipp, Philipp von Weitershausen wrote:
Stefan Behnel wrote:
If you want a bug-free release ready to install, then come and help us by testing the trunk and reporting any bugs you can find.
How about a 1.0beta release just to broaden the install base for this testing and bug hunting?
I also thought about that. We could release a 0.9.9 right away, so that people can give us feedback more easily, without having to run Pyrex and the like. However, I would then prefer having a single pre-release only before 1.0. Martijn, any objections to that? Steve, Olivier, Georges - could you please be ready to provide eggs for the beta release, so that we don't loose too much time before the release in June? A big thanks in advance to our helping hands, Stefan
Hello Stefan, Thursday, May 18, 2006, 4:55:04 AM, you wrote:
I also thought about that. We could release a 0.9.9 right away, so that people can give us feedback more easily, without having to run Pyrex and the like. However, I would then prefer having a single pre-release only before 1.0.
Martijn, any objections to that?
Steve, Olivier, Georges - could you please be ready to provide eggs for the beta release, so that we don't loose too much time before the release in June?
Sure, when should we build them ? Is the current trunk the beta release ? -- Best regards, Steve mailto:howe@carcass.dhs.org
Hi Steve, Steve Howe schrieb:
Hello Stefan,
Thursday, May 18, 2006, 4:55:04 AM, you wrote:
I also thought about that. We could release a 0.9.9 right away, so that people can give us feedback more easily, without having to run Pyrex and the like. However, I would then prefer having a single pre-release only before 1.0.
Martijn, any objections to that?
Steve, Olivier, Georges - could you please be ready to provide eggs for the beta release, so that we don't loose too much time before the release in June?
Sure, when should we build them ? Is the current trunk the beta release ?
That was too fast. :) When we release, I will upload a tar.gz to cheeseshop and send a mail to the list. That way, it's a clean release from clean sources. Stefan
Steve Howe wrote:
Hello Stefan,
Thursday, May 18, 2006, 4:55:04 AM, you wrote:
I also thought about that. We could release a 0.9.9 right away, so that people can give us feedback more easily, without having to run Pyrex and the like. However, I would then prefer having a single pre-release only before 1.0.
Martijn, any objections to that?
Steve, Olivier, Georges - could you please be ready to provide eggs for the beta release, so that we don't loose too much time before the release in June?
Sure, when should we build them ? Is the current trunk the beta release ?
I would advise making a tag. I would also advise NOT to call it 0.9.9 as this suggests some offspring from the 0.9.x line. Just call it 1.0beta, this is a very common naming scheme, even in Python :) Philipp
Hello Stefan, Thursday, May 18, 2006, 5:06:30 AM, you wrote:
When we release, I will upload a tar.gz to cheeseshop and send a mail to the list. That way, it's a clean release from clean sources. Ok, I'll be waiting for that. I should be travelling until money, however. If it gets release until then, I'll be doing it as I arrive back.
-- Best regards, Steve mailto:howe@carcass.dhs.org
Hi Philipp, Philipp von Weitershausen wrote:
Steve Howe wrote:
Hello Stefan,
Thursday, May 18, 2006, 4:55:04 AM, you wrote:
I also thought about that. We could release a 0.9.9 right away, so that people can give us feedback more easily, without having to run Pyrex and the like. However, I would then prefer having a single pre-release only before 1.0. Martijn, any objections to that? Steve, Olivier, Georges - could you please be ready to provide eggs for the beta release, so that we don't loose too much time before the release in June? Sure, when should we build them ? Is the current trunk the beta release ?
I would advise making a tag. I would also advise NOT to call it 0.9.9 as this suggests some offspring from the 0.9.x line. Just call it 1.0beta, this is a very common naming scheme, even in Python :)
Normally, yes. The thing is that lxml currently uses a "numbers-only" versioning scheme and I'd prefer keeping it that way, especially since the version will be accessible as int tuple in 1.0. So, "1.0.beta" will not work that well, as it will become something like (1,0,"beta",0)
print (1,0,"beta",0) < (1,0,0,0) False
is not quite the expected result. As a work-around, you could make it (1,0,-1,0) and special case the version string parser to represent "beta" as -1. I think that's a good idea. Any objections? Stefan
Stefan Behnel wrote:
Hi Philipp,
Philipp von Weitershausen wrote:
Hello Stefan,
Thursday, May 18, 2006, 4:55:04 AM, you wrote:
I also thought about that. We could release a 0.9.9 right away, so that people can give us feedback more easily, without having to run Pyrex and the like. However, I would then prefer having a single pre-release only before 1.0. Martijn, any objections to that? Steve, Olivier, Georges - could you please be ready to provide eggs for the beta release, so that we don't loose too much time before the release in June? Sure, when should we build them ? Is the current trunk the beta release ? I would advise making a tag. I would also advise NOT to call it 0.9.9 as
Steve Howe wrote: this suggests some offspring from the 0.9.x line. Just call it 1.0beta, this is a very common naming scheme, even in Python :)
Normally, yes. The thing is that lxml currently uses a "numbers-only" versioning scheme and I'd prefer keeping it that way, especially since the version will be accessible as int tuple in 1.0.
So, "1.0.beta" will not work that well, as it will become something like (1,0,"beta",0)
print (1,0,"beta",0) < (1,0,0,0) False
is not quite the expected result.
setuptools gets this right, though.
As a work-around, you could make it (1,0,-1,0) and special case the version string parser to represent "beta" as -1. I think that's a good idea. Any objections?
No idea why you need this number comparison. As said, setuptools gets this right anyways. Philipp
Hi Philipp, Philipp von Weitershausen wrote:
Stefan Behnel wrote:
As a work-around, you could make it (1,0,-1,0) and special case the version string parser to represent "beta" as -1. I think that's a good idea. Any objections?
No idea why you need this number comparison.
It's meant for version specific code. If we have a bug (or a new feature) somewhere and code needs it to work or can work around it, it should be able to do things like if lxml.etree.LXML_VERSION < (1,0,2): workAroundBugOrComplain()
As said, setuptools gets this right anyways.
We should not force software that uses lxml to rely on setuptools. Too many people do not have it installed. It's not required to run lxml, even ordinary users can install lxml from RPMs, .deb or windows installers. Stefan
participants (4)
-
iny+news＠iki.fi -
Philipp von Weitershausen -
Stefan Behnel -
Steve Howe