On 6/18/26 02:55, Tobias Burnus wrote:
Hello Jacob, hi all,
I am wondering whether there shouldn't be a new DejaGNU release
at some point. The last one was 5 years ago, cf.
https://ftp.gnu.org/gnu/dejagnu/
1.6 was released 2016-04-15 and 1.6.3 then 2021-06-16.
It seems as if some of the changes should make it at some point
into the distros, but that typically only happens for releases
and not for git versions (unless someone at the distro actively
tracks a project).
While there is no rush to do a release, please consider to do
one eventually, also because quite some changes have accumulated.
I have a roadmap with about 15 milestones that I want for a 1.6.4
release; 6 of those are checked off at the moment. In the meantime, Git
master has been accumulating various minor bugfixes as issues are reported.
The big goal is rewriting default_target_compile to use a table-driven
approach. I still need to rework the specs string model that I plan for
it to use. Initially, the specs strings will be internal to the
framework, but I plan to have a stable format and extension API in some
future release.
The plan calls for four layers: site customization (as ultimate
override), testsuite overrides, framework defaults, testsuite
fallbacks. The testsuite fallbacks are overridden by framework
defaults, but allow testsuites to provide defaults for languages or
tools not supported by the framework, with the possibility of merging
that support into the framework in the future and obsoleting the "out of
tree" version, which the testsuite must still carry to support older
versions of the framework.
Thanks for your steady work on DejaGNU!
You are welcome.
* * *
It seems as if 148 commits have been done after 1.6.3 branching
- or 101 if using 'git logdejagnu-1.6.3..master' as some 1.6.3 have
been merged to mainline.
NEWS currently only lists:
Changes since 1.6.3:
X. DejaGnu now always runs in the POSIX locale. Additionally,
environment
variables such as CDPATH that are widely-known and intended for user
customization are unset during early initialization.
Yes; NEWS is not always updated at the time changes are made and
reviewing it prior to a release is on the release checklist. NEWS also
only lists "significant" user-visible changes. Fixing bugs appears in
ChangeLog but usually not NEWS, for example.
One of the other items that I need to do at some point is some rework on
the repository; the history import was not quite right and I want to
move all of the tags off of the mainline because DejaGnu was always
developed with a "branch for release" model.
To fit that into Git's model with the slightly broken history import, I
am planning to move all tags from before the import onto "stub
branches": a backdated commit sharing its parent's tree object but not
itself a parent of any other commit. (The messages on those commits
will explain what actually happened.)
The slightly broken import itself is frozen into the history behind
GPG-signed release tags. It cannot be fully fixed, only documented.
The reason to remove/repoint/relocate the existing imported tags is that
`git fsck` complains about them.
There is also an option to add "relbase" tags at the points on the
mainline where releases are branched. If this is done, the changes
since master was branched for 1.6.3 would be relbase-1.6.3..master and
the changes as 1.6.3 went through release candidates would be
relbase-1.6.3..release-1.6.3.
What does the list think of this plan and that option?
-- Jacob
