at the same time I’m looking forward to v8.0 LTS - and I’m afraid of the upgrade process from v7.0 LTS.
Wouldn’t it be a good idea to create a script which does all the work? - AFAIK, we need to to 7.0 > 7.2 > 7.4 > 7.6 > 7.8 > 8.0, all step by step. Does it really make sense, that every fellow, for any instance he takes care of, does that manually?
I’d be happy to offer a little financial contribution to somebody who’d engage in this, I do not have the abilities to do it myself.
Thank you Sergi, that sounds nice. Nevertheless - does it really make sense that every single user collects all these commands and applies them manually? - Let alone understanding the not really comprehensive instructions. (yes I know, you understand them. I still don’t)
I know - that’s not a problem for you professionals. But I can tell you, it’s a serious one for us plain users. I stopped upgrading, because each minor upgrade step proved to be a nightmare (yes, to me; not to you, I know).
So, why not at least in this single case, act as a community?
Those operations are not automated because we can not automate them. Some must be executed only once but there are no way to know if they have been run or not. Some must be executed only in some specific cases.
If we could have automated them, we would have put them in the code like all the other “migration” operations.
Also I think we have quite reduced the number of manual operation needed over time. And we made them easier to get on the documentation.
But that does not make sense to my limited mind. In the upgrade process
either the required steps can be recognized by the machine - then a script can make the decisions
or the user (admin) needs to know some - then a script can ask, whether these should be carried out
I did not ask YOU for this script - I know you’re doing really more than enough for the Tryton project. But I don’t like you to block a community effort on this task with your answer.
But hey - as I learned about this “community” and its leadership… In this case as well, everybody will home-brew his own kind of solution, inventing the wheel several times separately and leaving those behind who don’t have the knowledge. Just the usual trytonian way of doing things…
Knowing this - I’d not once again start with Tryton. But now I’m trapped.
Can you point me to any example of manual operation which would cause trouble for being automated? also, is there any actual criteria to decide if a migration operation should be in the module code, or in the documentation? for example, why this operation could not be in the code among others: Migration — Tryton Documentation
I think having an automated update process would be a great time-saver for those with less developing knowledge, and overtime developers and system administrators could take some advantage to, so i’d like to give a try on a script in the tryton community which we could test overtime but before anything I just want to know real limitations.
Thanks.
I do not block anybody. I just point that our goal as developer is not to create manual operation for migration (on contrario).
So manual operation is used as last option and it is balanced with the benefit of the change.
But if someone come with a solution to prevent such manual operation, it will be welcomed but I do not want to let people think it will be easy otherwise we will already have done it.
I’d strongly recommend not to underestimate your influence, Sir. If a project leader (“know-it-all” by his self-assessment) says “it’s not possible” - then if becomes really hard for all the minor fellows to contradict.
So my great respect for @Xavi having dared this endeavour. Please let me know what I can do to support you. I’ve got a number of different local v7.0 instances in VENVs, most of them with core modules only.
And I think, community should support Xavi’s attempt by offering small financial appreciations as well.
