GIMP has been working towards a 3.0 release for some time, and I would like to publish a separate track to encourage testing of the beta releases. To that end, I would like to request that gimp be granted access to a 3.xpreview) track, please.
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
1 Like
The problem with using the latest/* channels for pre-release software is this is the default that will be installed when a user does not specify a track/channel, and is already used to hold the 2.x release which it will continue to do so - the latest/edge channel will therefore continue flip flopping between 2.x and 3.x depending on which was the last branch built - this is obviously confusing to users and very undesirable - I propose the rules be changed . Therefore a 3.x track makes the most sense as that is only installed on an opt-in basis. I anticipate that once stable the 3.x track will continue holding 3.x builds while the latest track will migrate to also holding the 3.x releases of upstream gimp. Then when gimp has a 4.x release we will move to having a 4.x track for those while in development and then stable releases thereafter which will also eventually be duplicated into the latest/* channels.
-
New major versions are historically very rare. GIMP is a 27 year-old project and we’re on 2.x major release currently.
-
I don’t know whether there is a commitment to maintain old versions once a new version is released, but I believe not.
-
config files I don’t know whether they’re backcompat. plugins I believe are NOT backwards compatible - at least the python plugins definitely aren’t as the previous version (2.x) used python2 and 3.x uses python3. xcf files I believe will be broadly compatible.
Ken mentioned that there is precedent for an “insiders” style track in other snaps, so maybe we could opt for that rather than a specific version number…?
Thanks for all the information - I think the use of a 3.0 track would be slightly confusing but as long as you’re aware of the pitfalls I’m OK with it. I’m also OK with having an insiders or preview track for these pre-release builds. You’re an experienced snap developer so having presented my point of view, I do trust your judgment and that you’ll use the track we end up creating properly
Im +1 to either 3.0 or an insiders-like name. Think about it and let me know which one you would prefer. We still have a couple of days to get votes from other @reviewers
- Danie
1 Like
+1 to a 3.x track for GIMP. This is similar to how we use tracks in Nextcloud-- each major version gets one (although we don’t use the “.x”, we’d just use “3” in this case which I think is slightly more user-friendly), and latest is generally pointing at the latest major version (although not always).
1 Like
I think, now that I’ve had time to digest a bit more, that to follow upstream as closely as possible an insiders or preview track name would be best - that way when they move onto future development after 3.x is stable we can continue using the same track for development releases and keep people who want stable releases on the latest track. We’ll still use the risk levels to indicate the latest track’s most stable to least stable releases - which will be more about changes to the packaging of upstream stable releases rather than upstream’s stability.
In that light I think preview would be most appropriate name. @kyrofa does your vote still stand with the change of name?
Of course, if you prefer preview I’m +1 on that as well.
1 Like
Thanks for your patience!
I’ve created a preview track for gimp.
It’s not too late to rename it if you prefer, but if preview is fine, you can start using it right away.
- Danie
1 Like