Existing snaps that produce i386 builds are supportable for the lifetime of Ubuntu 16.04 LTS or Ubuntu 18.04 LTS when using the core or core18 snaps as the base. Publishers who want to move to ‘base: core20’ must drop builds for the i386 architecture since it isn’t unavailable.
This presents a problem for publishers whose core/core18 builds are using the latest track and they want to move latest to core20. In my case, I wanted to continue to support i386 for the lifetime of Ubuntu 18.04 LTS, so I:
- created a non-latest track that will use ‘base: core18’ and snapcraft released appropriate revisions from latest into it
- created a branch of my project that continues to use ‘base: core18’ and push auto-builds (that includes i386) of this branch to the non-latest track (with master continuing to be pushed to ‘latest/edge’)
- updated ‘master’ to use ‘base: core20’ and drop i386 from the list of auto-builds
This works well enough organizationally but there are some problems:
- existing i386 users cannot be automatically migrated to the non-latest track
- new i386 users can’t use ‘snap install foo’ and must discover they should use the channel (that could be solved via documentation)
- the publisher needs to decide if it is better to close the i386 arch on latest or release non-latest/i386 builds to latest
In order to best support users, I think the best choice is to push the non-latest/i386 builds to latest so they at least get bug fixes, but this is awkward for the publisher and having a divergent codebase for i386 in latest is not optimal. Not to mention, different archs will have different support lengths within the same track.
Perhaps we should consider a mechanism to route arches to different tracks to handle this sort of thing?