Date
1 - 3 of 3
#yocto methodology to port from older yocto revisions to current #yocto
|
Monsees, Steven C (US)
Hello:
I am currently at Yocto release “Rocko 2.4.1” and I am looking into the effort to port to the latest Yocto release…
We have been using this rocko platform revision for the last few years in a project, and now want to move to the latest supported release.
Is there a preferred established methodology/guidelines when porting projects from much older established revisions of Yocto?
Is it considered better to port an established project directly to a new Yocto release, or to slowly migrate the yocto revision to the desired release ?
Thanks, Steve
|
|
|
|
Quentin Schulz
Hi Steve,
On Mon, Oct 19, 2020 at 11:22:41AM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote: You have a few of the changes highlighted in: https://docs.yoctoproject.org/ref-manual/migration.html Obviously, you'd need to do all the changes between Rocko and the version you're targetting (highly recommend dunfell (3.1) as it's an LTS). Is it considered better to port an established project directly to a new Yocto release, or to slowly migrate the yocto revision to the desired release ?I've done one upgrade only (krogoth 2.1 to thud 2.6) and it was direct, I'm not sure there's any benefit in doing incremental upgrades? Good luck :) Quentin
|
|
|
|
Alexander Kanavin
I feel that porting from an older Yocto release to a newer one is not the best approach. The delta can be very large, and it can be very painful and time consuming to handle it all at once. By the time you're done, the newer release may be already EOL or close to it. The right approach, in my opinion, is to track upstream master branches and stay as close to their tips as possible, solving any new issues as they happen in a manageable, predictable manner. Then you simply branch off releases when the corresponding branches are created upstream. Alex
On Mon, 19 Oct 2020 at 13:29, Quentin Schulz <quentin.schulz@...> wrote: Hi Steve,
|
|
|