* Automatically save the archive file after org-archive-subtree @ 2018-10-06 15:24 Kodi Arfer 2018-10-09 6:05 ` Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree] Adam Porter 0 siblings, 1 reply; 3+ messages in thread From: Kodi Arfer @ 2018-10-06 15:24 UTC (permalink / raw) To: emacs-orgmode As of https://code.orgmode.org/bzg/org-mode/commit/b186d1d7236c0dc397eadeb004c9a17eaffd3aab archiving a subtree no longer automatically saves the archive file. How can I get this behavior back? A Debian bug was also opened for this issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887332 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree] 2018-10-06 15:24 Automatically save the archive file after org-archive-subtree Kodi Arfer @ 2018-10-09 6:05 ` Adam Porter 2018-10-09 6:49 ` Nicolas Goaziou 0 siblings, 1 reply; 3+ messages in thread From: Adam Porter @ 2018-10-09 6:05 UTC (permalink / raw) To: emacs-orgmode Kodi Arfer <kodi@arfer.net> writes: > As of > > https://code.orgmode.org/bzg/org-mode/commit/b186d1d7236c0dc397eadeb004c9a17eaffd3aab > > archiving a subtree no longer automatically saves the archive > file. How can I get this behavior back? > > A Debian bug was also opened for this issue: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887332 According to that bug report, the behavior changed when upgrading from 9.1.2 to 9.1.5. I think this shouldn't happen. "Patch"-level releases (incrementing the third number) should only contain bug fixes. Changes which change default behavior belong in, at minimum, "minor" releases (incrementing the second number). Users should be able to freely upgrade from 9.1.x to 9.1.x+1 without having to worry about reading a changelog and adjusting their config to avoid changes in behavior which could lead to data loss. In my own (much smaller) projects, I follow this practice, which is basically SemVer. When I fix bugs, I apply the fixes to the latest stable branch, make a new stable patch-level release, and then merge the fixes into the master branch (in some projects, by rebasing the master branch on top of the stable branch, and in others, by a non-fast-forward merge of the stable branch into the master branch). The master branch becomes the next stable branch when its new features and other changes have been merged for long enough and have no known bugs. New features and refactorings are generally developed in a feature branch and then merged into the master branch when ready, eventually being released in the next stable branch. The master branch is intended to be always usable, but only recommended to users who are willing to potentially encounter bugs in new features or as a result of other significant changes. (In practice, this ends up being the branch used by 99.9% of MELPA users, but that's a MELPA-specific issue.) Most users should use the latest stable branch. This practice also makes it much easier for downstream packagers, like Debian, because changes to the stable branch are ONLY bug fixes. Could Org start doing this and call it Org 10.0? ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree] 2018-10-09 6:05 ` Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree] Adam Porter @ 2018-10-09 6:49 ` Nicolas Goaziou 0 siblings, 0 replies; 3+ messages in thread From: Nicolas Goaziou @ 2018-10-09 6:49 UTC (permalink / raw) To: Adam Porter; +Cc: emacs-orgmode Hello, Adam Porter <adam@alphapapa.net> writes: > According to that bug report, the behavior changed when upgrading from > 9.1.2 to 9.1.5. > > I think this shouldn't happen. "Patch"-level releases (incrementing the > third number) should only contain bug fixes. Changes which change > default behavior belong in, at minimum, "minor" releases (incrementing > the second number). [...] > Could Org start doing this and call it Org 10.0? We already do this. It just happens that this particular commit had deeper repercussions than intended. It was then considered as a bugfix and applied on the stable branch. Moreover, next release will be Org 9.2. Not Org 10. I think Org 10 will happen when some major part of Org changes, or when we drop support for older Emacsen, e.g., Emacs 24. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-10-09 6:49 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-10-06 15:24 Automatically save the archive file after org-archive-subtree Kodi Arfer 2018-10-09 6:05 ` Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree] Adam Porter 2018-10-09 6:49 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).