kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:
> I think starting small would be best in this case. The least needed
> would be a "News" File, that is always refering to kicad stable.
> 
> I propose the same way that patches with policy errors are rejected,
> patches that introduces new functionality or change of existing
> functionality are required to add to the News file, max one line. Just
> something like this, I would like markdown formatting.
> 
> 
> Changes from Kicad 4
> =
> 
> NEW: Pcbnew now supports clipboard copy/paste
> CHANGE: Delete button now removes entire trace, not just a segment
> CHANGE: Icons in toolbar are improved
> REMOVED: Autorouter no longer exists
> 
> 
> This style could also be applied in the git commit message, making it
> easy to compile by something such as 'git log | grep "NEW:"'
> 
> But since that is lacking, I think starting a new file is best.

I vote for git commit messages following a specific format (could be
NEW:/CHANGE:/REMOVE: lines) to easily create change logs. It is much
easier to see with git what has changed in a specific period of time.
With NEWS file you would need at least put dates there to be able to do
that (or see with git when a specific line has been added).

I know that ideally the user documentation should be updated together
with the code, but on the other KiCad changes so fast, so there might be
a lot of wasted time spent on changing the documentation and updating
screens that might be invalid in a week or two. For sure the
documentation should be refreshed for a stable release.

Regards,
Orson

Attachment: signature.asc
Description: OpenPGP digital signature