Does anyone actually find this useful? I was looking different processes and development workflows and when coming back to the “changelog” section of the module.xml it is terrible. I can only ask what du***ss thought this was the way. I actually know the answer to that it is rhetorrical lol. In any case I think they had it wrong and it has stuck because such is life. A long list of version numbers with vague one liners is minimally helpful, especially for things without a public ticket. Often on my android updates the “whats new” says “various performance improvements” … umm what?
I would suggest a changelog.md be kept in the module folder or elsewhere for historical review and the <changelog> in the module reflect changes to the current release… Version
Fixed Foo
Added bar
Ticket-2222 Replace some widget
Feature added to allow
Breaking: We did a thing that may not behave the way you expect
They aren’t using github actions, at least on their public repos. I can say for some of what they have to do there is no “off the shelf” actions. The stuff I work on internally at my company I have been building out a bunch of CI stuff including working on unit testing, linting, static analysis etc a long with packaging, encoding, signing etc. It is on my list to create a lite, open source version of my packager to allow community devs to automatically build and sign their modules on github releases. I would encourage anyone who is bored and knows this stuff and is familiar with PHP/Nodejs to start re-implementing Devtools as github actions where it makes sense. Note some of them haven’t been touched in 10 years so there may be nicer or cleaner ways to do much of that now. I generate actions using
which is nodejs based. If you like typescript
I am sure you can do them in any language given the motivation but boilerplates sometimes make things nicer.
P.S. When using the templates above remember to build before you test… otherwise you will waste cycles trying to figure out why your changes aren’t fixing things
I do recognize this is an issue that should be addressed (even though you should use more kind words!).
I don’t think keeping a changelog of the last version only is a feasible thing (if the user skip a version, won’t see the older ones), the best thing for me would be creating a totally separate changelog system with real XML tagging for every version and the UI could allow switching between versions or show some of the latest with a menu to expand older ones. In this case a fallback to the old .md changelog would be required for modules that still use the old method.
This could allow great improvements like links and styling of the text which would be great. Obviously this would require some changes in the core module (if I’m not wrong) to accomodate for the new system.
Just a note this wasn’t a design choice by anyone currently with the project. This was done by a certain Australian who is a good friend for almost 20 years now. He would dare use more colorful (I guess referring to an aussie Colourful) language that gets you a lot of heat in the states.
I loathe XML in general… Can we json up in here or something… We actually put code in place for 15 I believe to allow module.json but it didn’t go anywhere. Grand ideas… Anyway I was simply making a suggestion that took zero development effort to implement. There certainly are more ways to skin a feline. There is no reason we couldn’t have changelog.md just be “the thing”
Supports GFM (github flavor of markdown) so the files would look the same in both places and you could collapse old items.
