From: Bill Burdick <firstname.lastname@example.org> To: Tim Cross <email@example.com> Cc: Tom Gillespie <firstname.lastname@example.org>, "Dr. Arne Babenhauserheide" <email@example.com>, emacs-orgmode <firstname.lastname@example.org> Subject: Re: Changed list indentation behavior: how to revert? Date: Mon, 16 Nov 2020 23:35:36 +0200 [thread overview] Message-ID: <CAP6X8DjjZefePbJCr8sdtfNJEWHC4HJeQZdYecHKp9jcA34Quw@mail.gmail.com> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 3665 bytes --] Heh, I had time to read EMACS NEWS when I used it in 1985 (and still do for new EMACS versions). Now there are soooo many packages, each with their own news... -- Bill On Mon, Nov 16, 2020 at 10:59 PM Tim Cross <firstname.lastname@example.org> wrote: > > Tom Gillespie <email@example.com> writes: > > > Would it help if major releases maintained a mini-config that if added > > to init.el would allow users to retain old behavior? That way they > > wouldn't have to read the NEWS but could just add the relevant lines, > > or maybe even just call the org-old-default-behavior-9.1 or > > org-old-default-behavior-9.4. The workflow during development would be > > to account for any change to defaults in those functions. Thoughts? > > Tom > > If people don't have time to read the NEWS file, I also doubt they would > be aware of the mini config file or have the time to add it to their > setup. There would be an additional burden on developers to maintain the > mini-config which might not actually result in any real benefit. I would > also be concerned this might setup an expectation which is difficult to > meet. It may not always be straight-forward to provide such a > mini-config and sometimes, it may actually be in the best interests of > the user to force a change on them because it brings other benefits that > outweigh the initial 'change pain'. > > I do wonder if Org would benefit from adopting semantic versioning? This > could provide a way to convey more information to the user in the > version number e.g x.y.z => MAJOR.MINOR.PATCH where > > - PATCH = bug fix only. No changes to API or interface > - MINOR = extensions (additions) to API or interface, but no change to > existing API and interface > - MAJOR = breaking change - either API or interface has changed > > In general, my experience has been that the org developers have worked > hard to keep things stable in a very complex environment. The challenge > is when there is a breaking change, how to effectively communicate this > and minimise surprises for the user and how to accurately gauge the > impact from a change. > > At the same time, us users also need to take on some of the > responsibility and recognise that major version upgrades may break or > change their workflow. If you have a situation where stability of your > environment is critical to your work and your strapped for time so that > any change will be unacceptably disruptive, you need to adopt an upgrade > workflow which mitigates that risk. For example, my workflow allows me > to roll back any package which I upgrade. If I upgrade a package and it > breaks things and I don't have time to troubleshoot, I can roll it back. > Some distributions also include this feature. This is one area where I > feel the ELPA system could be improved. Right now, if you use the > org-plus-contrib package (or the org package) from either the org or > melpa package, it reports as something like org-plus-contrib-20201118, > which tells me very little apart from there is an update. I cannot tell > from this name if it is a major, minor or bug fix update. Not a big deal > for me as I can always roll back, but not everyone has that ability. > > Change is inevitable and if we focus too much on not changing existing > behaviour or API, we run the risk of overly constraining development. > Communication of change is a challenge, but critically important. I feel > we would get the most benefit by focusing on how to communicate breaking > changes effectively and ensure when such change is introduced, as far as > possible, details on how to restore the previous behaviour are provided. > > > -- > Tim Cross > > [-- Attachment #2: Type: text/html, Size: 4405 bytes --]
next prev parent reply other threads:[~2020-11-16 21:36 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-13 17:30 Karl Voit 2020-11-13 21:10 ` Gustavo Barros 2020-11-13 21:38 ` Jean Louis 2020-11-14 3:02 ` Greg Minshall 2020-11-13 21:47 ` Jean Louis 2020-11-13 22:13 ` Gustavo Barros 2020-11-13 22:21 ` Jean Louis 2020-11-14 17:28 ` Diego Zamboni 2020-11-14 19:10 ` Jean Louis 2020-11-15 12:44 ` Kévin Le Gouguec 2020-11-15 13:26 ` Jean Louis 2020-11-15 21:59 ` Kévin Le Gouguec 2020-11-15 22:15 ` Jean Louis 2020-11-16 7:15 ` Dr. Arne Babenhauserheide 2020-11-16 6:26 ` Greg Minshall 2020-11-14 10:45 ` Diego Zamboni 2020-11-13 21:31 ` Jean Louis 2020-11-14 22:43 ` David Rogers 2020-11-15 5:38 ` Jean Louis 2020-11-15 7:47 ` David Rogers 2020-11-15 8:54 ` Jean Louis 2020-11-15 10:37 ` Greg Minshall 2020-11-15 11:42 ` Tim Cross 2020-11-15 11:48 ` Gustavo Barros 2020-11-15 11:58 ` Detlef Steuer 2020-11-15 12:09 ` Jean Louis 2020-11-15 14:50 ` Gustavo Barros 2020-11-15 15:11 ` Jean Louis 2020-11-15 10:44 ` Dr. Arne Babenhauserheide 2020-11-15 11:22 ` Detlef Steuer 2020-11-15 14:03 ` Kévin Le Gouguec 2020-11-16 5:24 ` Kyle Meyer 2020-11-16 6:41 ` Tim Cross 2020-11-16 7:15 ` Tim Cross 2020-11-16 11:21 ` Gustavo Barros 2020-11-16 23:24 ` T.F. Torrey 2020-11-17 1:21 ` Tom Gillespie 2020-11-17 7:01 ` Dr. Arne Babenhauserheide 2020-11-17 7:48 ` Michal Politowski 2020-11-19 4:17 ` Marcel Ventosa 2020-11-16 8:06 ` Kévin Le Gouguec 2020-11-16 12:10 ` Bill Burdick 2020-11-16 6:54 ` Greg Minshall 2020-11-16 7:12 ` Tim Cross 2020-11-17 4:03 ` Greg Minshall 2020-11-17 5:25 ` Tim Cross 2020-11-17 13:15 ` Greg Minshall 2020-11-16 7:01 ` Dr. Arne Babenhauserheide 2020-11-16 7:22 ` Tim Cross 2020-11-16 16:04 ` Dr. Arne Babenhauserheide 2020-11-16 16:26 ` Tom Gillespie 2020-11-16 18:12 ` gyro funch 2020-11-16 18:48 ` Tom Gillespie 2020-11-16 19:41 ` Bill Burdick 2020-11-16 19:56 ` Tom Gillespie 2020-11-16 21:50 ` Tim Cross 2020-11-16 23:01 ` Tom Gillespie 2020-11-16 21:44 ` Tim Cross 2020-11-16 18:20 ` gyro funch 2020-11-16 20:56 ` Tim Cross 2020-11-16 21:35 ` Bill Burdick [this message] 2020-11-16 22:44 ` Tom Gillespie 2020-11-16 23:55 ` Dr. Arne Babenhauserheide 2020-11-17 9:05 ` Stefan Nobis 2020-11-17 9:15 ` Loris Bennett 2020-11-17 9:32 ` Diego Zamboni 2020-11-17 14:29 ` Dr. Arne Babenhauserheide 2020-11-17 16:25 ` Robert Pluim 2020-11-16 23:39 ` Dr. Arne Babenhauserheide 2020-11-16 21:35 ` Tim Cross 2020-11-17 0:11 ` Dr. Arne Babenhauserheide 2020-11-17 8:45 ` Detlef Steuer 2020-11-17 9:41 ` Jean Louis 2020-11-17 15:33 ` Maxim Nikulin 2020-11-16 13:00 ` Uwe Brauer 2020-11-16 16:10 ` Dr. Arne Babenhauserheide
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAP6X8DjjZefePbJCr8sdtfNJEWHC4HJeQZdYecHKp9jcA34Quw@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Changed list indentation behavior: how to revert?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this 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).