Hi!
Gimp has no existing tracks, so per Process for aliases, auto-connections and tracks , we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.
My main comment here is that using a track for evaluation or beta-grade software is not the intended use of tracks - it makes some sense if, once 3.0 is final, you intend to keep the 3.0 track as the “stable”, “most recent”, or “recommended” one, to start using the common “track per major version” pattern which is well-established with other snaps.
But tracks are really intended for stable but supported “legacy” versions. In that sense, the most common pattern would be to have a 2.x track and use latest for 3.0 once that’s out. Until it is, however, I understand it is of “beta” nature and it might be undesirable to publish it directly in latest/stable (it is, by definition, not yet stable 
). In that case, the beta (and edge and candidate) risks might provide a reasonable channel for publishing these beta releases. Would it make sense to use these?
Note I’m just mentioning it but I’m not opposed to the 3.0 track - just want to help explore alternatives so that we don’t end up with confusing track configuration for Gimp.
I also have the usual questions before casting my vote.
- What’s Gimp’s release cadence, how often is a new version (potentially requiring a new track) released? is this documented somewhere by upstream?
- Is there some commitment from upstream on maintenance of old versions?
- Are new versions backwards-incompatible? meaning, is the new version unable to read data files produced with older versions? (.xcf). Are the config files and plugins incompatible enough that one would want to not upgrade until a migration or conversion task for all the data and other artifacts has been run?
Thanks!
- Daniel