GNOME Bugzilla – Bug 791900
[PATCH] provide release information in AppStream file
Last modified: 2017-12-27 03:49:32 UTC
Created attachment 365909 [details] [review] Patch to add release information to the AppStream file This patch implements the <releases> tag of the AppStream spec, which makes it easier for downstream packagers to present release information to users. This requires some ongoing work from you: with each new release, you'll need to add a new <release> tag to the AppStream file, following the pattern in the patch. But it offers you significant advantages going forward: - Release communications, version numbers, and changelogs are centralized in your hands, making it more likely that downstream packagers will pass on this important information to their users - Release information becomes standardized across all distribution channels (distro packages, Flathub, etc). This is important for users who may have multiple channels active at once in their Software center apps (e.g. Flathub as well as their distros' packages). Here's the relevant section of the AppStream spec: https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-description
Thanks! That was also some of the changes I had in my stash though your patch is much more detailed and helpful (I just had a one-line description). Now I wonder if we must really have a <release> item for development releases as well. I think this should be limited to the stable releases because as far as people see from outside (i.e. apart people closely following development), GIMP 2.9.8 doesn't exist. In such a case, the <release> item in your patch should simply be promoted to 2.10. What do you think?
It's your choice, really. If you think there's any chance downstream packagers might want to package a version, then it helps them out to include a <release> tag for that version. Since the spec allows an arbitrary number of <release> tags, there's no real downside to adding more. We probably shouldn't add a 2.10 <release> tag until that release actually exists and has a release date.
> It's your choice, really. If you think there's any chance downstream packagers might want to package a version, then it helps them out to include a <release> tag for that version. We don't really want random distributions packaging a dev release of GIMP as though it were a "normal" release, because most people will be misled by such releases and think it is a stable version. If someone packages a dev release of GIMP, they have to make quit clear to people they are distributing them work-in-progress code with many known issue (among them stability issue where you can lose hours of work, and potentially format incompatibilities, etc.). > We probably shouldn't add a 2.10 <release> tag until that release actually exists and has a release date. But this should exist when the release is made, right? So basically a few commits before we tag our repository for the 2.10 release, we should add the <release> tag? Or you really mean that it must done *after* the release (when we will release 2.10.2 for instance)?
I'm not an AppStream expert, but I think it's fine to define 2.10 release information slightly before tagging 2.10. You probably don't want to do it weeks in advance though, or much afterwards! Since 2.10 isn't out yet, probably the release version we should add right now is for the latest stable release--that's 2.8? I'll mention that 2.9.8 is prominently mentioned on https://www.gimp.org/news/, with nice pretty release notes (+1). It's a little odd to feature it if you don't actually consider it public and make it easily available. If post-2.8 versions are supposed to be mostly-internal releases, maybe remove them from the news page?
Is this different to bug 779839?
Looks like the same thing to me!
(In reply to Nate Graham from comment #4) > Since 2.10 isn't out yet, probably the release version we should add right now is for the latest stable release--that's 2.8? Yes, I would accept directly a patch for the <release> tags containing 2.8.x information. If you do this and send me such a patch, I'll just push it. :-) This is only the 2.9.x that I am not sure we should have inside our release listing. Well, unless we have 2 appdata files, one for the stable releases and one for the dev releases (this last one would contain both the stable and dev release info). But that makes the process a bit complicated IMO. Though actually, it really depends on how this is presented in installers (I never saw this in GNOME Software and even looking at Recipes, which apparently has <release> tags, I don't see such release listing in GNOME Software 3.26). For instance, assume someone has GIMP 2.8.22 installed (as one should have!) and see a listing with 2.9.x but no way to install then through one's installer nor flathub or any common release medium. Also even if finally you find it by searching a lot, you may get misled into thinking this is a standard release. It has to be quite clear it is *NOT*. It is a risky release where your computer can explode and your data may get lost! That's what a development release is by definition. :P People are welcome to test them (ok we try not to have your computer explode ;p) knowingly, when they want to help development and report bugs. But this is not to be shown to any random person who has no idea what "development release" mean, doesn't care and only want stable versions for one's daily work. It would be nice to have properties in appstream format to tag a release as stable vs. dev for instance. This way, for instance, you would not show dev releases in the listing unless the current version is one! But I don't see such a property in the tag. I will contact Richard Hughes maybe and ask him what if we are supposed to add dev release info in the listing. > I'll mention that 2.9.8 is prominently mentioned on https://www.gimp.org/news/, with nice pretty release notes (+1). It's a little odd to feature it if you don't actually consider it public and make it easily available. If post-2.8 versions are supposed to be mostly-internal releases, maybe remove them from the news page? I think you are mixing everything up. :-) The 2.9 releases are not internal. They are public and *must* be easily available. Otherwise who will test them and report bugs? So yes, this has to be prominently exposed on our news feed and everywhere. Yet that does not make them "stable" release, the ones which are tried and tested, and that we provide for production. If you go in "gimp.org/downloads/" for instance, you will see that the version which we put prominently there is a 2.8.x. If our news were only used for stable releases, they would be quite boring! Of course, we also use them to talk about the project internals, the development releases, even interviews sometimes (and we want to do more community news).
Email sent to Richard Hughes.
Let's continue the discussion in Bug 779839. No need for duplicates. *** This bug has been marked as a duplicate of bug 779839 ***