kicad-developers team mailing list archive

[Kristoffer Ödmark <kristofferodmark90@xxxxxxxxx>]

I think for this to start happen, a decision has to be made, and 
enforced by everyone with commit access to the repo.

Bugfixes need not be tagged like this. Major changes only.

I still think a we should start collect a list in the repo with changes 
from kicad 4 up to the point this commit message policy is set. I for 
one love reading changelogs when upgrading, and I think the users are 
expecting this as well, and it probably will be useful in the FOSDEM 
presentation :)

On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:
> On 11/3/2017 8:54 AM, Maciej Sumiński wrote:
> > 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
>
> I'm not opposed to this idea but it should be used sensibly.  Not all
> new, changed, or removed code will require documentation changes.  I
> would also prefer it not be in the first line of the commit message
> unless the commit message is only one line.  It's already difficult to
> fit a descriptive commit title with only 72 characters.
>
> Cheers,
>
> Wayne
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

--
 -Kristoffer