Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge develop into master (commit to next release being breaking) #1904

Draft
wants to merge 421 commits into
base: master
Choose a base branch
from

Conversation

alerque
Copy link
Member

@alerque alerque commented Oct 30, 2023

This is so I can start keeping an eye on CI status for the branch linked from the milestone...

@alerque alerque added todo tooling Build tooling, release management, and packaging processes labels Oct 30, 2023
@alerque alerque added this to the v0.15.0 milestone Oct 30, 2023
@alerque alerque self-assigned this Oct 30, 2023
alerque and others added 25 commits November 4, 2023 07:01
BREAKING CHANGE: The current (pseudo) idempotent behaviour when loading
a package potentially clobbers anything that has been modified
since the last load. Loading a package, then modifiying a function it
provides, then loading the same package again will clobber the
modifiecation. This is good for idempotency but not very good for user
experience when you may not be modifiying all aspects of a document
render pipeline at once, as in when using templates.

This change makes the default behaviour to run setting, raw handler, and
command registrations only once. An altertanive to :loadpackage() called
:reloadpackage() can be used to force all these registrations to be
rerun when the goal is to make sure of a specific state.
Co-authored-by: Alex Orlenko <zxteam@protonmail.com>
Co-authored-by: Alex Orlenko <zxteam@protonmail.com>
This is cool but not very useful because it is constantly out of sync
with how upstream mantains the file. Style changes, dependency changes,
Ruby function changes, etc. all affect this no to mention our own local
build changes. These are harder to backport to the perl than it is just
to manually update the upstream formula.
These macros are identical across a bunch of projects I work on, hence
the naming scheme. I eventually decided it was confusing to know which
macros came from the autoconf-archive and which were my own, so not
using the AX_ prefix except for things that could be dropped and used
directly from the archive just makes sense.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
todo tooling Build tooling, release management, and packaging processes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants