view admin/notes/years @ 80390:59863894d837

Replace MenuHandle and GetMenuHandle with MenuRef and GetMenuRef, respectively. Replace WindowPtr with WindowRef. Replace ControlHandle with ControlRef. [!TARGET_API_MAC_CARBON]: Include Quickdraw.h instead of QuickDraw.h. (install_menu_quit_handler): Rename arg MENU_HANDLE to ROOT_MENU. [TARGET_API_MAC_CARBON] (menu_target_item_handler): Don't call next handler. Return immediately unless popup is activated. [TARGET_API_MAC_CARBON] (install_menu_target_item_handler): Remove argument. Install handler to application. (set_frame_menubar): Don't change deep_p. (mac_menu_show): Use FRAME_OUTER_TO_INNER_DIFF_X and FRAME_OUTER_TO_INNER_DIFF_Y. (DIALOG_BUTTON_COMMAND_ID_OFFSET, DIALOG_BUTTON_COMMAND_ID_P) (DIALOG_BUTTON_COMMAND_ID_VALUE, DIALOG_BUTTON_MAKE_COMMAND_ID) [HAVE_DIALOGS]: New macros. [HAVE_DIALOGS] (mac_handle_dialog_event, create_and_show_dialog): Use them. (fill_menu) [TARGET_API_MAC_CARBON]: Use SetMenuItemHierarchicalMenu. (fill_menubar) [TARGET_API_MAC_CARBON]: Use CFString. (mac_dialog_modal_filter, Fx_popup_dialog) [MAC_OSX]: Put special treatment for Fmessage_box, Fyes_or_no_p, and Fy_or_n_p in #if 0 as it is not compatible with y-or-n-p-with-timeout. (timer_check) [TARGET_API_MAC_CARBON]: Add extern. [TARGET_API_MAC_CARBON] (mac_handle_dialog_event): Use QuitEventLoop instead of QuitAppModalLoopForWindow. Consolidate QuitEventLoop calls. (pop_down_dialog) [TARGET_API_MAC_CARBON]: New function. [TARGET_API_MAC_CARBON] (create_and_show_dialog): Use it for unwind. Run timers during dialog popup. (Fmenu_or_popup_active_p) [TARGET_API_MAC_CARBON]: Use popup_activated. (quit_dialog_event_loop) [TARGET_API_MAC_CARBON]: New variable. [TARGET_API_MAC_CARBON] (mac_handle_dialog_event): Set it if dialog event loop should be quit. [TARGET_API_MAC_CARBON] (create_and_show_dialog): Quit dialog event loop if quit_dialog_event_loop is set.

How to Maintain Copyright Years for GNU Emacs
  (see also file "copyright" in this directory)

"Our lawyer says it is ok if we add, to each file that has been in Emacs
 since Emacs 21 came out in 2001, all the subsequent years[1].  We don't
 need to check whether *that file* was changed in those years.
 It's sufficient that *Emacs* was changed in those years (and it was!).

 For those files that have been added since then, we should add
 the year it was added to Emacs, and all subsequent years."

 --RMS, 2005-07-13

[1] Note that this includes 2001 - see
<http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-12/msg00119.html>


For the refcards under etc/, it's ok to simply use the latest year
(typically in a `\def\year{YEAR}' expression) for the rendered copyright
notice, while maintaining the full list of years in the copyright notice
in the comments.

------------------------------------------------------------------------------


Following is the policy that we tried to write down one time (mid 2005).
Although it is incorrect, we keep it around to remind us how complicated
things used to be (and may become in the future).


Principle: Individual files need to have the year of the release
           in the copyright notice if there is significant change.


Practice:

- individual files
  - each must be examined, along w/ its history, by a human
  - automated tools facilitate but can never replace this process

- year of the release
  - may be different from year of file introduction,
    or year of last significant change
  - sometimes the release year slips, leaving a file w/ prematurely
    marked release year => need update (e.g., s/2004/2005/ for Emacs 22)
  - intervening years (between releases) are not valid and may cause
    embarrassment later in case of dispute => remove (however, see next)
  - years for new files (merged, contributed) that have been separately
    published are valid even if between releases => leave alone

- significant change
  - insignificant
    - whitespace
    - copyright notice
    - version control tags
    - simple var/func renaming
    - in-file reorganization/reordering
    - typos
    - small bugfixes
    - small docfixes
    - filename renaming
  - most everything else is significant
    - change to interface
    - change in functionality
    - new file
  - many small changes may be significant in aggregate

- when in doubt, ask (and update these guidelines -- thanks!)

- sometimes people make mistakes
  - if they have not read these guidelines, point them here
  - if the guidelines are not helpful, improve the guidelines