Will the last suggestion in that thread not work?

https://img.shields.io/badge/dynamic/json.svg?uri=https%3A%2F%2Fapps.fedoraproject.org%2Fmdapi%2Ff27%2Fpkg%2Fpython3-enlighten&query=%24.version&label=Fedora+27

I suppose we would need to document things somewhere so github projects know whats available.

No, the whole point is we have to use half solutions like that because nothing better exists. For example, with that one, while it determines the package dynamically, you still have to update badge for the latest version of Fedora. Almost all web services that support badges have a latest option and have some sort of shorthand so the badges are easier to implement.

You may also want a badge like the ones I first mentioned in the thread which describe which releases a project has packages for rather than the versions available.

If we make badges flexible and easy to implement it gives maintainers a good way to point people to Fedora and EPEL and it serves as a reminder to keep packages updated.

I think this may be a good idea for a small application one could write and run in communishift (when it comes back).

At this point I do not think that this is something we want to do and maintain ourselves.

Therefore, as much as I think the idea is interesting, I would propose that we close this ticket.

I'm not sure closing it makes sense it's something we want to do.

I've also noticed Fedora badges are available in Sheilds.io now, but they are not very robust and are still static, requiring both the branch name and the name of the package within that repo (ex: python36-enlighten). I think a pull request to improve the badges there would be a good start, and once we're happy with them we could point people there via documentation.

I can help with that, but I'm not sure which API to use. The current one uses mdapi. For the badges on my projects, I'm using PDC to list branches for the ones I use. Maybe Bodhi's api is the one to use?

I think we'd want a few forms:

Fedora: {Version in latest fedora release}
EPEL: {Version in latest EPEL release}
Fedora: {Fedora versions that have the package}
EPEL: {EPEL versions that have the package}
Any others?

What API calls are needed to determine this information?

I am most happy to help you figure out how to build this but I still don't think this is something the Fedora Infrastructure team wants to development and maintain.

As for the answer to your question, it'll be a mixed of apps:
- mdapi will give you the version in a specific release (be that Fedora or EPEL)
- PDC will give you the list of active releases for a package
- Bodhi will return you everything unless you restrict to what you wish to know and that will require knowledge that is present in PDC.

I'm not seeing the autogenerating api docs for bodhi like the others have, but perhaps I'm not looking in the right place. Where can I find examples of getting JSON back from Bodhi REST queries?

It uses the Accept header to determine if it should return HTML or JSON, so if you hit bodhi with curl, you'll get JSON :)
After you just need to find the URL from the UI and query it.

For example:

curl "https://bodhi.fedoraproject.org/updates/?packages=guake" | python3 -m "json.tool"

Awesome, thanks!
What is the source of truth to determine the latest Fedora and EPEL versions? I assume there is some flag to indicate when they are released and not in a pre-release status.

As much as I hate myself for this, the best answer to this day may still be pkgdb2 (which has been retired, is no longer running but because some apps still rely on its API being there, we're still keeping up to date and serving: https://admin.fedoraproject.org/pkgdb/api/collections )

Beware that it will go away eventually, we dearly want it to go away, but so far it's still there.

Otherwise, you could poke at PDC for say: fedpkg which is present in all Fedora and EPEL versions and see which branches it has.

PDC was what I was thinking, but I wasn't sure how to tell that f32 is the latest stable branch vs f33.

@aviso do you need more information?

Are you ok with us closing this ticket?

I haven't had a chance to dig into it. Still a bit unsure about determining the latest release. I don't want to rely on something scheduled to go away.

@aviso are you still waiting on more information on this?

I propose we close this ticket off, and reopen when and if you start working on it.

I haven't had time to look into it. I'm not sure closing the ticket makes sense since it hasn't been implemented. This is a good task for a volunteer to take on.

This one being open for 3 years with no takers. Additionally, @pingou 's comment that this is likely not something that the infrastructure team has the resources to either develop and maintain in the future.

That is why i am leaning towards closing this off until there is someone interested in developing and maintaining something like this.

I don't see how that's justification for closing it. If you close it, you lose signal. I think there's general agreement this is something we want, but it is low priority, so keeping it open with low priority makes sense. Closing a task just because no one is working it or because it's old makes no sense.

I don't see how that's justification for closing it. If you close it, you lose signal. I think there's general agreement this is something we want, but it is low priority, so keeping it open with low priority makes sense. Closing a task just because no one is working it or because it's old makes no sense.

There are different ways to manage a ticket tracker:
- Use it as a way to keep all ideas, bug reports, RFEs
- Use it as a way to track work that will be done. Tickets that are valid but
will not be worked, are closed. Closing a ticket does not take anything away
from the idea discussed, it just indicates that it will not be worked on.

We tend to have the second approach for our ticket tracker. We want to keep open
tickets that we will work on, and thus we want to minimize the number of tickets
open.
This ticket is 3 years old, CPE has indicated that they do not have the
resources to work on it and in 3 years no-one else in the infrastructure or
overall Fedora community has stepped in to work on this.

I am therefore +1 on closing it.

The ticket can always be re-open when someone wishes to work on this.

Sure, the second approach is used, but in studying IT processes over the last decade, it's generally not recommend. That approach is correlated with lower quality and higher churn. This is because the emphasis is on what can be done with the resources available rather than on how can the resources available be utilized to produce the best product.

So I'd recommend leaving it open. Otherwise how is someone going to know it needs to be done?

it needs to be done?

Does it though? It's been three years and no one has felt like it needed to be
done.

I'm neat-picking there and you have my apologies for that.

At this point, I think we have both clearly expressed our opinions and we'll
have to agree to disagree.
Maybe other can chime in and we can see if a consensus emerges for either
approach.

I definitely see both positions here, but I'd side with the closers. There's a vast pile of things we 'could do someday', but keeping them in our tracker clutters things up, takes our attention, etc.
Perhaps we need another place for a 'ideas containers' or 'it would be nice if we...' or 'wishlist' items?

As far as moving this ahead theres a few things we could do:
Could we just ask shields.io to do what we need? ie, move this issue there.
Might be this would make a ok summer of code/outreachy project? I think to be useful tho it would need a more detailed project acceptance critera
* Perhaps this could be advertized to the new websites and apps team?