Comments (9)
@muzimuzhi -dev releases are for testing and yes, sometimes they show a breakage that was intorduced by mistake. That doesn't mean that we immediately intoroduce a new release. Please understand that overall making a dev release results in several hours of work for both us and the CTAN folks combined and we have to be careful in managing the limited resources here.
from latex2e.
you wouldn't expect in this case that CTAN keeps 2 releases of main, would you?
Nope, I wouldn't. I am only talking about the point, where dev
is not up-to-date with main
. But now I can see, that this isn't the point and I am talking nuts.
At the time when 2024-06-01 pre-release 1 was released, \IfInstanceExist(TF) were both removed from the new kernel code and latest xtemplate package.
By reading "new kernel code" I mistakenly assumed, that this is already out in main
. But we are only talking about an intermediate state of dev
. And well, that is something what could happen as the name intends.
As far as I can see, there is actually a new release of dev
with every major relase of main
. The case where main
is ahead of dev
occurs only if there is a new patch release but this is fine, I guess.
Sorry for the noise.
from latex2e.
Sure, but this is a pre-test ;) So it's always possible you have to make minor adjustments in your sources as things get tested.
A new dev release is likely before Easter, we are just finishing off some additions and will likely agree on things on Tuesday.
from latex2e.
@FrankMittelbach I totally get this argument. But as developers are encouraged to use latex-dev
in order to detect possible breakages early and they do this in an automated test suite---not that I am doing this, long outstanding issue for myself---than those regression can get annoying like in the case of @muzimuzhi. Wouldn't it be possible to create an identical release for latex-dev
with every major release? Or would this need the whole manual process for latex-dev
as you described?
from latex2e.
My take on this is that one can and should have a testsuite set up so that it can use either or latex or latex-dev format. Yes we encourage developers to test against -dev but obviously you also need to test against main because most of your users will be using main andd if something is reported as broken one needs to see what fails with main and how to fix that.
So the idea is that a test suite should report success with main and you should regularly run it using -dev and see if this this breaks anything and if so report a problem to us -- or fix your code to work both with current main and -dev aka upcoming main if it is a legitimate change.
For example, I run all of the TLC3 sources against -dev usually to ensure that the book is not broken with the next main, but because of the \IfInstanceExistTF issue I had to fall back to "main" at the moment and wait for a new -dev release to appear.
The "identical release of latex-dev for each major release" is the latex release without -dev in the name so I'm not what you are asking and yes making another release with a different name introduces the same amount of work ... it is making a release that is the work (and get it through all stages) even though a lot of it is automated.
from latex2e.
My take on this is that one can and should have a testsuite set up so that it can use either or latex or latex-dev format.
Agreed
The "identical release of latex-dev for each major release" is the latex release without -dev in the name so I'm not what you are asking and yes making another release with a different name introduces the same amount of work ... it is making a release that is the work (and get it through all stages) even though a lot of it is automated.
I asked having some automated test suite in mind running for both latex
and latex-dev
formats which could fail running latex-dev
like in the case @muzimuzhi described. Having both releases in sync would not break any tests for latex-dev
without any obvious reason. But as I said, I totally get the point regarding the efforts to take. I just wondered if this would be achievable easily.
from latex2e.
@FrankMittelbach I totally get this argument. But as developers are encouraged to use
latex-dev
in order to detect possible breakages early
I guess that's what I feel is happening: you test, there's an issue, you patch round it until the next dev release ...
from latex2e.
I asked having some automated test suite in mind running for both
latex
andlatex-dev
formats which could fail runninglatex-dev
like in the case @muzimuzhi described. Having both releases in sync would not break any tests forlatex-dev
without any obvious reason. But as I said, I totally get the point regarding the efforts to take. I just wondered if this would be achievable easily.
sorry, I'm still not getting what you are after.
Suppose you have a simple setup:
- your test suite just tests against main
- now we put out a hotfix for main (or we release a new main)
- your test suite breaks
- if the breakage is caused by something bad in your package you fix your package
- otherwise you report an issue with us (but your test suite remains broken until this is fixed or you temp program around it)
you wouldn't expect in this case that CTAN keeps 2 releases of main, would you?
Now assume your test suite runs both main and -dev tests
- now the -dev release suddenly breaks
- if that is due do something you shouldn't have done in your package or because we cleaned things up and some interfaces require adjusting, you update your package so that it works both with main and upcoming -dev
- otherwise, something is wrong with the new -dev and you report it
- then for the time being you have to disable -dev tests until we have a new -dev out
- that is precisely the same as if main breaks and we need to have a hotfix out (only that with main it is more urgent and we try to make that happen fast usually)
What I could envision (and perhaps that is what you are asking) is some flax or config setting that allows you to run your test suite in 3 modes:
- only main
- only -dev
- both main and -dev
but to have yet another full latex distribution as in latex-previous-dev seems overkill to me because that is much better done by not testing -dev for a while (but maybe you didn't mean that).
from latex2e.
yes we add a dev 0 very soon after each main (just wait a bit in case we have overlooked something and need a patch release) so usually, dev is ahead of main (and even after a new release of main it is more of less = to main so on this front we are usually ok even in the daves directly after the main release).
as a new dev is going to show up real soon* I'm going to close this issue.
from latex2e.
Related Issues (20)
- eliminating ".tex" file special case in kpathsea HOT 12
- Size and hash of historic version of a package HOT 5
- ltkeys: Omitting `=` while defining a key throws low level error HOT 12
- Hooks to set attributes for different parts of the page. HOT 1
- doc documentation (bug?): 'symbolic' name for \levelchar in \index{} example on page 11 produces garbled entry HOT 1
- User-defined marks swallowed if inside multicols HOT 1
- Macros defined with \newcommand are protected when they have an optional argument, but expand fully when they have no optional argument HOT 3
- Empty hook raises error with label-specific message HOT 1
- Extra \endgroup in \AddToHook HOT 5
- Label redefinition - with just one label HOT 1
- Add \protected status to \begin
- `letter.cls` documentation contains offensive term HOT 1
- latex-dev: version is required in luatexbase.provides_module HOT 3
- \dots fails if followed by commands involving primitive `\if`
- Single-branch forms of CamelCase conditionals, continued HOT 1
- Missing composite command for โi with macronโ HOT 1
- Documentation of \ShowCommand HOT 3
- \hook_debug_on: does not log changes made by AddToHookNext HOT 3
- Drop unnecessary \@noitemerr in \addvspace and \addpenalty HOT 3
- usrguide.pdf: Mention space-trimmed aspect of \NewDocumentEnvironment et al.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from latex2e.