[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
elpa.git and `new-master`
elpa.git and `new-master`
Mon, 14 Dec 2020 23:46:17 -0500
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
As part of the effort to setup the NonGNU ELPA infrastructure, I've also
overhauled the GNU ELPA part.
Part of the result is that now all packages are kept on separate
branches (no more "subtree"s). As a result, the `master` branch has
shrunk significantly.. Especially since even the deployment script
themsevles have moved to a separate branch (`elpa-admin`) so as to be
able to share them between elpa.git and nongnu.git (it also comes with
the side effect that this FSF-copyrighted code is kept in `elpa.git`
rather than `nongnu.git`).
Here are some immediate news linked to this:
- I have now changed elpa.gnu.org to use the new code to build the
tarballs of GNU ELPA. Please be on the lookup for any regressions.
- The old `master` branch has shrunk to almost nothing, yet it still
carries in its history all the code it used to have. This is not
a big issue since that code is still around. More importantly, the
`master` history includes some entries which Git nowadays considers
"not quite valid" (resulting in bugs#22690 and bug#25376).
As a result, I decided to create a fresh `new-master` branch which
doesn't share its history with `master`. This new branch will replace
`master` in the coming days. So whoever is tracking `master` will be
faced with a "non-fast-forward" update.
This can be annoying and I apologize in advance, but I think the
long terms advantages largely make up for the short term annoyance.
- On the positive side, the new code has some interesting features:
- It knows how to build Info files from Texinfo files, so we won't need
to store the generated Info files any more.
- It also know how to generate Info files from Org manuals.
- It can even run `make` as part of building the tarballs, making it
possible to perform various massaging.
This obviously can't just run "anything you like" since it depends
on what's available on `elpa.gnu.org`, so if you want to use this
feature, please get in touch with me so we can coordinate it.
There is an embryo of documentation of those new features in the
`README` file in the `elpa-admin` branch.
This should hopefully make it possible to build a Tramp tarball
directly from the code in Emacs, or similarly for AUCTeX avoid the
need to store generated files in Git.
The `Org` package is an example that uses some of those new features
to build the tarballs directly from an unadulterated copy of the
- Another advantage is that the new code makes it much easier to build
your own tarballs, for example to test them before pushing to code.
You can just do `make build/[PKGNAME]` and the resulting package will
be built in `archive/[PKGNAME]-[VERSION].tar.
- A subtle but important change affects the exact code placed in the
tarballs. The old code detected the need to make a new release
tarball by watching for changes in the `Version:` header and whenever
it saw a new value, it built the tarball from the HEAD revision.
The new code detects the need in the same way but will not just use
the HEAD revision: it will use the specific revision that modified the
`Version:` header. This means you can push a commit that bumps the
`Version:` together with a bunch of subsequent commits that introduce
wild bleeding edge changes without fearing that the release will
actually be made from the bleeding edge code. It also means that if
you see a remaining bug after you've bumped the `Version:`, there's no
point quickly pushing a subsequent fix unless you also re-bump the
Re: elpa.git and `new-master`, Stephen Leake, 2020/12/15
- elpa.git and `new-master`,
Stefan Monnier <=