"Martin v. Löwis" writes: > I'm all in favor of formalizing a policy of when Python releases > are produced, and what Python releases, and what kinds of changes > they may contain. However, such a policy should be addressed > primarily to contributors, as a guidance, not to users, as > a promise. So I have problems with both "official" and "support" > still. I see your point, but I don't see how you propose to keep the users from viewing the guidelines to developers as official policy regarding support, albeit hard to interpret. Also, it may just be me, but I don't see an official statement as a "promise". It's a "clarification". '''This is what we're trying to do, so you can make well-informed plans, and not be surprised when you ask for something and we say "but we never thought about doing that, and don't intend to".''' > The way we make policy statements is through the PEP process. Creating the statement that way is important. But publishing a PEP is not enough. Non-developer users don't read PEPs. After thinking about it a bit, I do agree that "maintain" is more appropriate than "support" (this is after my reply to Terry Reedy, where I wrote that support was OK). Support implies education and adaptation to user needs, but even if that is done by the PSF, it's a separate activity from the development and release processes. While maintenance does include response to user bug reports as part of the development/release process.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4