On Fri, 2026-05-08 at 11:05 -0500, Michael Catanzaro wrote: > We don't have a version limit for shotwell in rawhide, so it will > inevitably be updated whenever somebody next runs mclazy: > > https://forge.fedoraproject.org/workstation/mclazy/src/branch/main/modules.xml >
Thanks for the pointer to mclazy. > I don't think it's a good idea to use rawhide version limits unless > we really want to ensure a package is never updated *ever* again, > like for gtk3 or glibmm2.4. Otherwise, we'll forget to remove the > limit. > I would argue for the opposite. Set the limit to 0.32.x for the time being (for 43, 44 and rawhide) and and I'm pretty sure users (I'm also one) will file a request to upgrade to version 33 once it has been released. > My suggestion is GNOME maintainers should just not create unstable > releases unless they intend to do a stable release within the next > few months. The unstable releases exist to be packaged, after all: > there is no reason to create them if you don't want distros to > package them. That just doesn't make sense. So I'm actually OK with > shipping the unstable version. But alternatively, we could remove > Shotwell from release automation, and only update it manually. > I hear you, but I think it's just unrealistic to expect all GNOME maintainers / apps to follow this time-based twice-a-year release schedule. As long as I remember, Shotwell has always been quite slow in its development cycles and it just doesn't make sense to package an unstable release and hope a stable release will follow with the next few months. > This is a problem for non-GNOME packages as well, like Flatpak. > Upstreams should think carefully about what they are trying to > achieve in creating an unstable release. Do you expect distros to > package it, or is there some other purpose for the unstable release? > I think this would be appropriate for a wider discussion with the upstream maintainers. On Fri, 2026-05-08 at 09:05 +0200, Tadej Janež wrote: > > Going back to the stable series in the f44 and rawhide will be tricky. > > Given Fedora 44 has just come out, I think this demands a quick > reaction before even more users upgrading from earlier Fedora > versions > are affected. > > In practical terms, the reasonable thing would be to "downgrade" the > package to the 0.32.15 release from Mar 1, 2026 and set the Epoch to > 1 to ensure a smooth package "upgrade" from 0.33.alpha to 0.32.15? I submitted a PR to Shotwell package to downgrade to the latest stable version (0.32.15): https://src.fedoraproject.org/rpms/shotwell/pull-request/9 Should I notify maintainers on some other channel as well or is this enough? > A must is to also check if there were any backwards-incompatible > changes to the configuration or SQLite db schema in the 0.33.alpha > release. If there are any, these need to be carefully considered... AFAICS, both versions use the same version of SQLite db schema: https://gitlab.gnome.org/GNOME/shotwell/-/blob/33.alpha/src/db/DatabaseTable.vala?ref_type=tags#L24 https://gitlab.gnome.org/GNOME/shotwell/-/blob/shotwell-0.32.15/src/db/DatabaseTable.vala?ref_type=tags#L24 so downgrading should not cause any issues. -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
