Appimagekit: Procedural Request: Start maintaining a Change Log

[cculianu]

I noticed you guys did a release last month -- and I am updating my build system now to use it.

I am curious -- what went into version 12? Where are the release notes? As much as I love reading commit logs, it would really save some time if the releases were distilled down into a "release notes" or "what's new" list. Can you guys start doing that as part of your release procedure. It would really save me (and maybe others?) tons of time..

Thanks.

[probonopd]

Hi cculianu, we generally recommend to use the continuous build, so you benefit from all new changes automatically. The tagged releases are just "known good" fallbacks actually.

[cculianu]

Yes, but where is the change log? :)

[cculianu]

I realize I'm coming across like a pedantic douche. But your project is otherwise so extremely well maintained of otherwise such high quality, (with extremely good documentation) -- that I was surprised at the lack of a change log or a digest form that explains what's changed.

As far as the commit log goes: I actually ran through the commit log and while I do agree that code speaks for itself -- perhaps your fellow developers would be well served if you added more descriptive commit messages. Eg don't do:

commit -a -S -m "changed stuff"

but do:

commit -a -S <--- and use the editor. Write more than 1 sentence if you can for anything non-trivial.

I'm really sorry if this comes across as passive-aggressive or non-appreciative.. I appreciate all the work you guys are doing and am tremendously impressed by the otherwise great quality of this solution.

Take my feedback as something to consider, if you want. Thanks.

[probonopd]

Thanks for your suggestion, we will try to do better with the commit messages. Kudos for the documentation go to @TheAssassin, the blame for sloppy commit messages go to me.

[cculianu]

Your documentation is incredibly good and useful, I appreciate it. Hey I used to do lots of short commit messages too until others screamed at me about it and I got better. You guys are doing great. 👍

A changelog.. would be nice.. hehe. But it is fun to do code archeology anyway and actually helps me understand how your tool is built.. so there's that. :)

[probonopd]

Welcome to AppImage :-)
We would highly appreciate if you could consider contributing to the documentation, if only in the form of asking questions.

[shoogle]

don't do:
commit -a -S -m "changed stuff"
but do:
commit -a -S <--- and use the editor. Write more than 1 sentence if you can for anything non-trivial.

Agreed, but make sure that...

1. __The first sentence works as a summary on its own__
   
   
   
   • The first sentence is used as a subject in automated emails about the commit.
   
   
2. __The summary is less than 72 characters__
   
   
   
   • Otherwise it will be truncated by software tools (e.g. GitHub's online viewer).
   
   
3. __You leave an empty line (press Return twice) after the summary.__
   
   
   
   • Otherwise the next paragraph will be treated as a continuation of the summary
   
   

For more tips writing commit messages see:

• https://commit.style/
  
  
  
  • https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53
  
  

[probonopd]

This is the UI I mostly use...

I practically never work with a CLI git client.

[cculianu]

Am I the only one that still uses vi from CLI?

But yes, I agree. 1st line summary < 72 chars (and keep all lines below 72 chars to be safe)

[TheAssassin]

Probably. I use nano.