Replies: 2 comments
-
I think the way this is done in the Git world is to require an issue that each change closes. I hadn't been doing that but I will from now on. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I’m thinking of something at a very fine-grain, something for each source file or subsystem. On git, would that be dividing things up so that each source file is a project?
… On Oct 27, 2020, at 8:42 AM, Larry Masinter ***@***.***> wrote:
I think the way this is done in the Git world is to require an issue that each change closes. I hadn't been doing that but I will from now on.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <https://github.com/Interlisp/medley/issues/56#issuecomment-717332965>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNCN4MB3L5CRHXNG4TSM3TABANCNFSM4S73E74A>.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
If we are going to approximate some for of check in, branch, release, mechanism, we should also implement standardized tools and conventions for encouraging changelogs for invididual source and library files, if not also lispusers. We automatically record the edit date and editor at the top of each function, and we can add comments at the top of the function or flag them at the place where an edit was made. But we don't have a systematic way of recording changes to non-functions, and we don't have a separate running history of the sequence of changes for a given source. A inside-lisp package that makes it easy to append to a per-file changelog at the time of the edits would be useful.
Beta Was this translation helpful? Give feedback.
All reactions