"LTS" Py4Web?

[Nazywam się Witek]

Can we create a version of py4web with long-term support (and DAL)—with its issues, but with code that doesn't change much—that I can fix with minor security patches or minor bug fixes? I need something stable for my own project customization over the long term. Ideas are great, but they lead to chaos, and I don't know at what point I'd consider this a version I want to customize to the specific project requirements "for the long term." For example, 3-5 years?

[Alan Etkin]

py4web is released periodically with version numbers. I think that instead of LTS there should be some repo with releases by number so when you find your app code broke by a change you can revert the framework code to the working version. I'm not sure if this can be handled directly with GitHub versioning, if so, then it's just about maintaining py4web code with the correct version.

Regards

Alan

[Massimo DiPierro]

I think pending some tweaks to custom widgets that will be settled soon, I think py4web is already very stable. I agree with Alan but I also see the pros of an LTS version. I will consider that as soon as we have closed the reamining pending PRs. Very soon.

[laundmo]

I would recommend relying on standard python and git tools to stay on one version:

- If you don't need to modify py4web/pydal source, use python dependency management to pin your project to a specific version: in requirements.txt or pyproject.toml specify py4web==1.20250921.1
- If you need to modify py4web/pydal, fork the git repositories for your own modifications: on github, click on the "fork" button at the top. Then git clone your fork, and run "git reset --hard <ref you want>" - the ref can be a commit hash or a git tag. There should be a tag for each py4web version. Make your changes, git commit them and then git push them. Then, specify your own fork in your dependencies like this: py4web @ git+https://github.com/<your_github_username>/py4web

If you make a fork, and your changes could be useful to the main version, you can also make a Pull Request, to ask massimo to add your changes to the main repository/version.

[Alan Etkin]

>There should be a tag for each py4web version.

https://github.com/web2py/py4web/tags

Even you can download the source of each tag to deploy it

[Nazywam się Witek]

Thanks for the tips. But Massimo seems to have understood my point best.

It's similar to the current web2py. I want to slightly modify the py4web code using classes inheriting from ~from, grid, and/or monkey patching.

I want to discover the source code in detail (memorize it in my head) and write code based on what I know—even if I know something isn't working properly.

However, sometimes bugs are discovered, for example, security bugs (~XSS, etc.). I'm not an expert in everything.

What's my option then?

Do I have to migrate to the current patch release? (Will numbered versions receive patches?)

How can I do this with ~100,000 lines of code/~200-300 tables, major changes to the current version, and a critical project?

The "LTS" release would be a stable (frozen) version where I could expect some (hopefully) support in fixing a small piece of code. Nothing revolutionary.

If the version cannot be repaired - information ~LTS version 1.0 cannot be (easily) repaired - migrate to version 2.0 or live with CVS awareness.

[Kathy Botlar]

Great thread! It’s completely valid to ask for a “long-term support (LTS)” version of py4web that remains stable, especially if you’re building something that you’ll be modifying or maintaining for several years. As one contributor put it:

“If you don’t need to modify py4web/pydal source, use python dependency management to pin your project to a specific version… mine is (Cinema)” 

Here are a few thoughts:

• Pinning a version via requirements.txt or pyproject.toml is a practical way to lock in stability while you work. 

• If you do plan to customize deeply, then forking the repo and managing your own branch might be the safer route — so you control changes and patches.

• Maybe talk with the maintainers about establishing a defined branch (say lts-2025) where only bug-/security-fixes go, and feature changes go elsewhere. That could merge the best of both worlds.

In short: Yes, an “LTS mindset” makes a lot of sense for serious projects with long lifecycles.

[Massimo DiPierro]

I thought more about this and I think it is a good idea. I think we need a few more tweaks to the grid before freezing it. In particular we need to include some of the improvements proposed by laundmo.