Re: How about a roadmap?

[J.P.]

Hi people,

Here's what I'm thinking for June and the latter half of 2022. Some Q3+
items won't make sense without additional context, which I'm happy to
provide. But it's also fine to just regard them as opaque placeholders
in what's really just a sketch to block out the basic shape of things to
come. The Q4+ stuff is still wide open, so feel free to take a chainsaw
to it if need be. As usual, leading numbers approximate the relative
cost of closing an item.

Q2

   4 Buffer-naming collisions
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598
     This omnibus initiative also includes the following:

     - New entry-point :user keyword
       https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54824

     - Simplify mutual loading dependency
       https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54825

     - Fix clumsy prompt handling on reconnect
       https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54826

     - Make buffer-display behavior safer (bug#51753, 1/2)
       https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51753

   2 Improve handling of multiline prompt input
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54536

   1 Investigate package.el issue impacting next release [1]

   1 Paper over some 27 compat issues temporarily
     `format-patch', `decoded-time-period', etc.

   1 Improve frame-oriented buffer-display options (bug#51753, 2/2)
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51753

   * v5.5

Q3

   2 Explore alternate pre-release versioning workflow [2]

   2 Begin exploring long-term strategy for managing compatibility

   4 Lay some IRCv3 groundwork
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49860

     - Improve module handling generally and provide local modules
       https://ttm.sh/tax

     - Perform additional prep work, like making stamp and fill more
       flexible, converting core message handling functions to
       cl-generic, and possibly submitting an authz patch for sasl.el

   3 Devise convention for promoting experimental features in releases,
     possibly by partitioning the internal "erc--foo" quasi-namespace.

     - Expose core v3 functionality and SASL as experimental features,
       or possibly export a tiny, forward-compatible corner of the
       eventual public v3 catalog
       https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29108

   * v5.6

Q4

   5 Formalize sustainable policy for all things compat

     - Launch compat-centric CI/CD and bug-oriented ELPA

   5 Finish core IRCv3 suite and export library functions

   2 Add buffer refilling feature
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51969

   2 Track user modes
     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51082

   * v5.7

2023

   5 Empower existing options with context-specific granularity

   5 Decouple protocol, transport, and display

   * (possible 6.0)


Notes
~~~~~

[1] The problem is that package.el (on 28+, at least) does not like
    packages reporting more than one maintainer. But that's what ELPA
    describes ERC as having if you build a package from trunk. In
    `package-menu-mode', clicking an offending package's name triggers
    an error in `package--print-email-button': it expects a cons of two
    strings (a name and an email) but gets a list of such conses
    instead.

    One makeshift solution would be to duct tape over the problem for
    now with a bubblegum patch for elpa-admin.el, something like:

      https://ttm.sh/tay

    A lasting solution might be to fix the bugged package.el schema and
    increment its version (and maybe provide a migration script in Emacs
    28.2, although that's probably unnecessary). Of course, all this is
    contingent on the assumption I'm using elpaa correctly, which may be
    far from the truth.

[2] By "alternate pre-release versioning workflow," I mean some way of
    conveying that the version of ERC on trunk is ahead of the current
    release. The rubric currently in effect and touched on here

    
https://git.savannah.gnu.org/cgit/emacs.git/plain/admin/notes/elpa?id=c0807dae

    has us iterating on a source that shares the same version as that on
    ELPA. IOW, as it stands, we only increment the version number of our
    working copy (the one on HEAD) just before publishing to ELPA. But
    it'd be nice to instead do that just *after* publishing without
    triggering yet another release. (Tramp appears to use the suffix
    "-pre" for a similar purpose, although I believe it's developed
    externally, so perhaps that's apples and oranges).

    In any case, such a change would help prevent unforced errors when
    handling options and other items containing version metadata. It
    would also make for easier engaging with users who run a copy of
    master for which `emacs-repository-version' comes up nil, likely one
    built from an unofficial tarball like those supplied by GitHub.