[windle]

I'm sorry you feel that way, as the developer of Pylons, I really don't look at this as killing Pylons anymore than the lack of any new functionality has killed Pylons 1.0 in the past 6 months.

Pylons 1.0 has been in maintenance mode already (effectively), 1.0 was in fact nothing more than a few tweaks on 0.9.7, ie. maintenance release with a 1.0 version number and finally killing a few deprecated things.

The FAQ explains why when attempting to extend Pylons for new functionality, I hit a dead-end: http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just...

Finding a path forward for extensibility that didn't hit this forking problem: http://lincolnloop.com/blog/2008/apr/4/reusable-django-apps-...

was a very major concern of mine. I think this will address that, and when Django makes the changes necessary to remove the forking problem I won't be at all surprised if it requires porting your apps...

[d0mine]

Why Pyramid is not called Pylons 2?

[windle]

We had originally considered calling it p2, unfortunately that would've sort of bound the package name to sound kind of odd when someday we get to Pylons 3. Also, given the amount of new code to merge in, and then slowly deprecate the old code in the pylons package... it seemed more convenient to use a new name.

This also means that no one installing the 'pylons' package will have to worry about someday installing a version that deprecated things their old pylons app needed. Using pyramid means that you can use the new, along with the old one, at the same time, without worrying about version conflicts in the package.