Feeds builder #452
Unanswered
miniscruff
asked this question in
Ideas
Replies: 2 comments 1 reply
-
Hello @miniscruff Here is my quick feedback that reflect perharps only one posisition (mine). RSS may be a cool feature if open-source projects that were hosted on GitHub did not have a similar watch features solution since a long time now. |
Beta Was this translation helpful? Give feedback.
1 reply
-
Being able to show only the most recent release would be nice since github release feed doesn't do that. Could be useful for an organization github landing page and showing the most recent release from each repo instead of all. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A potential feature idea I have been thinking about is using changie to generate a news feed ( atom, RSS, json feeds, etc ) that you would then host and allow users to subscribe to. This would take some configurations and "append" entries for each release using the generated release notes into an existing feed file. Or it could generate a separate
{version}.{feed name}.{feed-type}
file as part of batch, that together with a feed template or header generate a feed when merging. ( Probably a go template file to be honest )The output would be sort of similar to the GitHub releases feed but more customizable. See Changies releases feed or a preview here, to see your own projects feed the url path is:
https://github.com/:org/:project/releases.atom
.Some vague hypothetical configurations could be:
I feel like creating some sort of
{VERSION}.{FEED-TYPE}.{FEED-EXT}
file for each batch, then when merging, in addition to merging the release notes to the root changelog, merge the feeds into a shared feed would be the way to go. There is also the case of migrating existing config values into its own feed structure, liketype: changelog/release notes/semver
but it is kind of baked into how batch and merge functions with file names and sorting, so unlikely unless it was required to exist. For example:This change would be a pretty major breaking change if required, but to support both would not be too hard for compatibility reasons as it is just moving from one location in the config to a new location.
Anyway, all of this is just an idea that would take a fair amount of work and a bit of configuration on the project side. So, the real question here is, would anyone use this and should it be built and maintained? Also, it would be implied that versions built before any feed configuration was added would not have any feed entry built and you might have to write them manually for existing versions as all the metadata required to build them are lost in the batch process ( unless you use
--keep
).Beta Was this translation helpful? Give feedback.
All reactions