I think this might be better handled as bugs on the kicad-doc repo. Then everyone can contribute easily and we can track it for the documentation, where the info is to be used anyways. For now label them new_kicad_feature if it is.
2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark <[email protected]>: > 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 : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> > -- > -Kristoffer > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
