I’m nervous about using a git checkout [commit hash] . to pin a version of Frappe and ERPNext. It would be great if Bench 1) had the ability to do this based on the semantic version the team uses and 2) this may be a middle ground instead of a true LTS option for Frappe and ERPNext. I think there are going to be a lot of people who will need and want to stick with the last V10 release for python 2.7/ 3 reasons. Unfortunately not everybody can track with Frappe’s pace of development so having the ability to “land” on a version or for service provider teams to specify a version to support their customers.
1 Like
I think you can do
git checkout v10.0.7
to use a specific version
Does it make sense to write a for wrapper this into Bench and the bench version command?
1 Like
My vote for the CLI API would be something like:
bench version prints the versions of installed apps - the same as it does now
bench version --app erpext --pin [args] where args are in v10.1.30 or 10.1.30 syntax or the commit hash. leaving off the “v” is probably better, no?
To undo it, something similar: bench version --app erpnext --unpin
Having bench update checkout these versions before updating would be the most useful feature. Maybe even adding an --unpin option there?
Mmmm, yes, it can obviously be done, but I don’t believe just adding it to bench would suffice!
A new (major) version means lots of new features, but at the same time, it also means a whole lot of bug fixes. The new features need not percolate into the older versions, but bug fixes would need to. Currently I don’t believe we do this, unless it’s a major bug we’re looking at. So this would mean additional work (going through every commit deciding if it should or not seed into the previous version/s) and maintenance for the release team, and given sometimes things are rewritten from scratch for improved efficiency it would also mean a whole lot of merge conflicts whose improper resolution could lead to further breakage in the older systems.
Also pinning a single app would be a difficult thing to do. Since frappe and erpnext both need to be on the same version to function properly. Since lots of new features for ERPNext go into the main framework as well.
So to sum it up . I’m not sure how feasible it is. On one end I feel erpnext is better following a rolling release, but on the other the LTS and the customer’s point of view put forth by @tmatteson does make a lot of sense!
Maybe we could have the community maintain the older versions for bug fixes and stuff!?
2 Likes
There are branches created for old versions when new version is released.
e.g. GitHub - frappe/erpnext at v4.x.x, GitHub - frappe/frappe at v9.x.x, etc
My “Bench is not the solution” flavored concern would be enforcing a match of the database schema between app version changes. If I run bench update to make sure everything is good in 10.1.30 and then have to support a (theoretical) customer who is pinned on 9.x that’s definitely going to cause mismatches and errors in the db. From a stability standpoint the rolling release practice is just making breaking changes often and as small as possible; some customers can’t handle that at all. Just like how major or minor a bug is is a matter of opinion (and money).
So requiring the ERPNext and Frappe version to match sounds like easiest part of this. This seems like a good topic for the foundation to at least research (maybe starting with a poll of foundation members?). My optimistic self thinks that Bench is the best tool for this because it’s the one we have, it’s already installed on every system and is already managing releases.
Perhaps restricting the ability to pin within major semantic version X is enough of a starting point? I realize that makes it less useful, but it’s a good start.
1 Like
Thanks @revant_one. I think this convention facilitates the sort of minimal changes we’re talking about. I had forgotten about it but it’s certainly helpful. The documentation is beginning to write itself!
I had another thought about version checking while doing an install this morning. It would make sense to warn the user if their frappe and erpnext applications are not both on develop or master. Also I tried the technique Faris suggested
git checkout v10.1.31
because frappe and erpnext were on 10.1.31 and 10.1.33 this morning and it complained about it. It makes sense to me to offer a warning about this as well, even though it won’t be very common to have that problem, it falls pretty far into the “advanced configuration” realm…
1 Like