LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0
Content-Type:
text/plain; charset="UTF-8"
Date:
Mon, 27 Aug 2018 05:08:36 +0200
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Benjamin Berg <[log in to unmask]>
Message-ID:
In-Reply-To:
Content-Transfer-Encoding:
7bit
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (27 lines)
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

ATOM RSS1 RSS2