https://bugzilla.redhat.com/show_bug.cgi?id=2137159 --- Comment #9 from Mads Kiilerich <mads@xxxxxxxxxxxxx> --- Just to make it clear: My motivation for speaking up here is just to get good Ardour packaging, and to stay consistent with upstream "reality" so the packaging remains as good as possible. Upstream considers all "major" and "minor" releases the same regarding new features, UI changes, risky refactorings ... and thus the risk of regressions. There are generally no low-risk "patch" releases (and thus never any updates that are suitable for existing Fedora releases). (7.1 might be an exception - it might come soon and be a "hotfix".) *All* versions promise to be fully backwards compatible, so for example 7.0 can open back to (most) Ardour 2.0 sessions (and upgrade to the 7.x format). "Major" .0 releases are *only* different in that they introduce a new file format, which remains forward compatible with all "minor" releases in that series (but can't be read by previous releases). That means that there *could* be a potential use case for having 7.0 and 7.1 side-by-side and smoothly go back and forth if 7.1 in some way should be considered a regression. That use is *not* covered by the current scheme. Having 6.9 and 7.0 side by side seems less relevant. While 7.0 can read (and update) everything 6.9 can read (and write), 6.9 can't read anything from 7.0 . There is thus not much use for having them installed side by side. I think it would be sufficient to pin / versionlock at the old release. But that use case *is* the one covered by the current scheme. There is also a use case for making 7.0 available for preview, for example in the existing Fedora 36. With Fedora's 6 month release cycle, I don't think it is a big use case. I think that use case could be covered copr ... or by using binaries from upstream. But that use also seems to be a goal for the current scheme. I would thus suggest to just let the "ardour" package move forward in rawhide, and generally not update it in released Fedora releases. Other "compat" packages could be made on demand. (In reply to Guido Aulisi from comment #4) > Having separate packages was almost a must when versione 3 was released. It > was really incompatible with version 2 and the migration of the session file > had some bad bugs. Sure. No doubt there has been problems in the past where temporary desperate measures might have been justified. It is hard to guess what bugs might show up in the future. I would guess that it is more likely that "minor" versions *without* session migrate introduce changes with problems with forward or backward compatibility. I'm thus no big fan of letting previous unique experiences dictate current behaviour. All software has bugs, and some releases turns out to be worse than others. One solution to that is to package *everything* in several versions. I understand that is kind of how Debian does it. But I prefer the Fedora way of having one canonical version of each package, where it is up to the packager to decide if it is sufficiently ready, and help out (or patch) to make it happen. (In reply to Nils Philippsen from comment #5) > (In reply to Mads Kiilerich from comment #3) > > I think that putting the first part for the version number in the package > > name is a bad idea. The package name should just be "ardour". > > I think I remember we talked about this before, yeah. (I don't think we have discussed it before. But others might have the same concern.) > The naming is done > this way according to the guidelines for the reasons I’ll go into below: > https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple According to that: * One package SHOULD use the base name (with no version information). * The package version, which SHOULD include the periods present in the original version. It should thus be for example ardour (with 7.0) and ardour6.9 . That would address my concern. (I still consider don't it relevant to have them side-by-side, but the 6.9 will not do any harm ;-) ). > Not using semantic versioning doesn’t preclude incompatible breaks between > one major version and the next though… Sure. But it also doesn't preclude incompatible breaks between two "minor" versions. Thus, if we want side-by-side packages, we must also be prepared for having for example 7.0 and 7.1 side by side. > For reference, here's the discussion on the mailing list: > https://lists.fedoraproject.org/pipermail/music/2015-May/002005.html Some comments to what is said there: * "Installing "ardour" will always get you the latest available version" yes please! But that is not what we see now. * "Every major version gets its own package" Ok. But 7.1 might in most regards be just as "major" as 7.0 was, so for consistency that one should get its own package too. > > * Ardour 7 can read (and upgrade) Ardour 6 projects. There is no particular > > good reason these two versions should be installed side-by-side. Supporting > > evidence: Upstream no longer makes Ardour 6 (easily) available for download. > > This is all good in hindsight, but as I understand it, there are no > guarantees that this will be the case for future major versions. Nobody can guarantee that there never will be bugs or change of plans. But upstream explicitly state commitment to remain backwards compatible, going so far back that 7.0 can open (most) Ardour 2.0 sessions. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2137159 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
