|
From: Chris L. <ch...@ka...> - 2012-09-10 12:58:24
|
Hi Everyone, I'd like to get a 1.2.5 release out the door so we can properly start on Python 3.x support and a 1.3.0 release. I've copied the remaining issues from sourceforge to github and added the blockers for a 1.2.5 release to the 1.2.5 milestone. Any help people can give with triaging these issues would be greatly appreciated. Many of the outstanding bugs are for htmlfill which I don't use so if you are an htmlfill user and can comment or provide a concrete test case that would be very helpful. The plan is that 1.3.0 will drop support for at least python 2.3 and probably 2.4 and 2.5. Anyone using 2.4 or 2.5 should speak up about their need for continued support. -Chris -- Christopher Lambacher ch...@ka... |
|
From: Ian W. <ven...@gm...> - 2012-09-11 06:52:46
|
I have something coming up this weekend, but maybe the next weekend? Did you want to set a date for some sort of mini-sprint? On Mon, Sep 10, 2012 at 5:58 AM, Chris Lambacher <ch...@ka...>wrote: > Hi Everyone, > > I'd like to get a 1.2.5 release out the door so we can properly start on > Python 3.x support and a 1.3.0 release. I've copied the remaining issues > from sourceforge to github and added the blockers for a 1.2.5 release to > the 1.2.5 milestone. Any help people can give with triaging these issues > would be greatly appreciated. Many of the outstanding bugs are for htmlfill > which I don't use so if you are an htmlfill user and can comment or provide > a concrete test case that would be very helpful. > > The plan is that 1.3.0 will drop support for at least python 2.3 and > probably 2.4 and 2.5. Anyone using 2.4 or 2.5 should speak up about their > need for continued support. > > -Chris > > -- > Christopher Lambacher > ch...@ka... > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > FormEncode-discuss mailing list > For...@li... > https://lists.sourceforge.net/lists/listinfo/formencode-discuss > > |
|
From: Felix S. <fel...@os...> - 2012-09-11 07:26:19
|
Am 10.09.2012 14:58, schrieb Chris Lambacher: > The plan is that 1.3.0 will drop support for at least python 2.3 and probably > 2.4 and 2.5. Anyone using 2.4 or 2.5 should speak up about their need for > continued support. We use FormEncode in MediaCore (www.mediacorecommunity.org) and there are still many customers using 2.4 (roughly 20%). I plan on supporting 2.4 in MediaCore for the foreseeable future (2-3 years) though some smaller features might be 2.6+. I'll stop supporting Python 2.4 for all libraries I maintain on March 2017 when RHEL 5 goes EOL. That being said MediaCore uses FormEncode only in simple functionality and we don't need new FormEncode features so I guess we can stay with 1.2.5 for quite some time. fs |
|
From: Chris L. <ch...@ka...> - 2012-09-14 16:00:46
|
On Tue, Sep 11, 2012 at 3:09 AM, Felix Schwarz <fel...@os... > wrote: > I'll stop supporting Python 2.4 for all libraries I maintain on March 2017 > when RHEL 5 goes EOL. > RHEL6 looks like it supports 2.5 and 2.6 would you then need 2.5 support or your app would work with the latest version available on the system OS? > That being said MediaCore uses FormEncode only in simple functionality and > we > don't need new FormEncode features so I guess we can stay with 1.2.5 for > quite > some time. > I'll do a maintenance branch for 1.2 before we start on 1.3 and we can continue to do bugfix releases but maybe people using older versions Python should start pinning their versions or FormEncode to < 1.3 so that you don't get version that don't work for you on PyPI. I want to have a mixed 2.x 3.x code base and not have to deal with 2to3 and some of the things you need to do to make it work with older versions of Python (like < http://docs.pythonsprints.com/python3_porting/py-porting.html#handling-exceptions>) are not pretty. Making 2.6 be the lowest supporte version make things much simpler. -Chris -- Christopher Lambacher ch...@ka... |
|
From: Felix S. <fel...@os...> - 2012-09-14 19:02:04
|
Am 14.09.2012 18:00, schrieb Chris Lambacher: > RHEL6 looks like it supports 2.5 and 2.6 would you then need 2.5 support or > your app would work with the latest version available on the system OS? RHEL 6 provides only Python 2.6. MediaCore works on Python 2.4-2.7 (whatever the user chooses). The main difficulty is that it's software installed by random users on their various environments. And it turns out a number of hosts still only provide 2.4 (usually on RHEL/CentOS 5). > I'll do a maintenance branch for 1.2 before we start on 1.3 and we can > continue to do bugfix releases but maybe people using older versions Python > should start pinning their versions or FormEncode to < 1.3 so that you don't > get version that don't work for you on PyPI. Version pinning is no problem for MediaCore, that was done by the old maintainers anyway (we host all dependencies on the project server so also Pypi downtime does not affect users). A stable 1.2 branch with security fixes only would be actually great solution to us! > I want to have a mixed 2.x 3.x code base and not have to deal with 2to3 and > some of the things you need to do to make it work with older versions of > Python (like > <http://docs.pythonsprints.com/python3_porting/py-porting.html#handling-exceptions>) > are not pretty. Making 2.6 be the lowest supporte version make things much > simpler. I didn't have any troubles using 2to3 on a code base and thus supporting Python 2.3 - 3.2. The only real PITA is doctests which are (IMHO) not portable. Heck, I even had troubles for different versions of Python 2.x when the repr output for a class changed (Decimal in 2.4 vs. 2.5+). fs |