References:  <b82e8c205ad01b9f6e95b8c482ce192873f2070e.camel@sipsolutions.net>
             <bd4e695d-79ac-249f-5f85-2e8b1832c183@morningstar2.co.uk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID:  <0bd9377ae896d7b54baa292a2f7b6e4254f4ec13.camel@sipsolutions.net>
Date:         Mon, 27 Aug 2018 05:08:36 +0200
Reply-To:     Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender:       Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From:         Benjamin Berg <benjamin@SIPSOLUTIONS.NET>
Subject: Re: \ior_get_str:NN vs. \ior_str_get:NN
To:           LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <bd4e695d-79ac-249f-5f85-2e8b1832c183@morningstar2.co.uk>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Hey,

On Sun, 2018-08-26 at 09:36 +0100, Joseph Wright wrote:
> Simply put: update your code.

OK, I get that, and there is only so much you can do obviously.

> We provide a two TL-cycle period for people to update their packages, 
> before removing deprecated commands. The *strong* likelihood is that 
> users updating package X will also update expl3, and vice versa: for 
> most end users, updating is done using their TeX system.

The problem for me is that I am shipping the package separately, which
means that I am confronted with whatever version the user already has
on their machine. This obviously completely breaks the above
assumption, and I fully understand if there is no intention to support
this corner case better.

That said, is there maybe a relatively straight forward workaround,
e.g. by testing for the LaTeX 3 version at package build ("unpack")
time and emitting different code from the DTX file based on that?

My idea right now is that a version switch in the INS file to modify
the \generate call could be a viable workaround for me.

Benjamin