Release tags?

[mxmilkiib]

Hi, I'm trying to import the release feed into https://libreav.org using a sanitised version of each entries tag in https://github.com/pedrolcl/kmidimon/releases.atom but the order of the releases seems to have been mixed together on import, as can also be seen on https://github.com/pedrolcl/kmidimon/tags.

Might it be at all possible to somehow edit these to have a more consistent/linear order, if GitHub allows that?

[pedrolcl]

Hi!

Github is not the primary host for this project, here is only a Git mirror of the primary Subversion repository at Sourceforge. Both should be synchronized, so Subversion commits in trunk become Git commits in master, but I don't publish releases at Github for this project. Releases are available here: https://sourceforge.net/projects/kmidimon/files/

Tags are not the same as releases, neither in Git or Subversion. Think of tags like milestones, or landmarks on the timeline. I usually tag every release, but sometimes there are tags to mark something else, like the 'root_kde3' tag. It was created just in case a branch should be created at that point. Every tag is associated with a commit, so you can refer a particular commit by a symbolic name tag, for instance: 235b6b6 is the nearest Git commit to Subversion r241, which is the tag 1.1.0 commit at Subversion: https://sourceforge.net/p/kmidimon/code/241/

Sourceforge also offers RSS feeds. Please read https://sourceforge.net/p/forge/documentation/RSS/

Try this Files RSS feed: https://sourceforge.net/projects/kmidimon/rss?path=/
Or the News RSS feed: https://sourceforge.net/p/kmidimon/news/feed.rss
Or the project activity feed: https://sourceforge.net/p/kmidimon/activity/feed

About your request for editing the tags, I guess that you mean renaming the tags so their names reflect the chronological order. I don't want to do that, because then the tag names would be different at Git and Subversion. There is also a tags view in Sourceforge: https://sourceforge.net/p/kmidimon/code/HEAD/tree/tags/ And there the tag names are listed also in alphanumeric order (of course). But in that case the Date column has the correct value, and you could use that column to order chronologically the list, if you find a way to turn that link into a RSS feed.

Or do you mean something else?

[pedrolcl]

I have an issue on my own about https://libreav.org

I am the author of several MIDI related software apps and libraries. Some are for Linux only like Drumstick MIDI Monitor and Drumstick Metronome, which are referenced in the site you are contributing.

But then, some other projects are totally omitted:

• VMPK
• Dumstick MIDI File Player
• wrk2mid
• SonivoxEAS

Why?

[mxmilkiib]

I was using the SF news feed previously, and, for all feeds, parsing release version numbers from feed entry titles. That has been fairly brittle, as, if a developer gives a release a title on GH, GH then overwrites the version number title with that freeform title thus requiring requests for developers to prepend their own release titles with the version number and an ugly stack of regexes to pair everything down to just a version number. I decided switching to using GH feed entry elements, which usually after its last / gives a much easily parsible version number. Unfortunately only GH provides that concisely useable element; SF populates it with a hash. Also, there are more than one project in the feed in this instance, something I was hoping that looking beyond SF might be able to help with also. There is no good answer in such an edge case I think.

For not having added the other projects, well I've just not gotten around to it yet.

[pedrolcl]

Depending on GitHub only is quite risky. Using GH as a backup is tolerable, but what if they decide to close/change/whatever their feeds. I don't want to put all my eggs on that single basket, knowing Microsoft.

I may create releases without assets in this project, like I do for instance in https://github.com/pedrolcl/dmidiplayer/releases

VMPK 0.1.0 was released in 2008/08/29. That is 13 years 2 months 3 weeks and 2 days ago.

[mxmilkiib]

Yeah, it's tricky. Best of a bad bunch imo atm, even with the outages and changes, even with M$. I mean, SF at least used to make direct download links hard, had the dodgy installers, and refuses to invest to improve their end-of-the-00s interface. GH was innovative enough to allow a more-or-less parsable unique id element that reflects the release number/version, not a hash. I'll probably otherwise go with self-hosted Gitea (e.g.) installed via Yunohost once go-gitea/gitea#569 is finished.