Re: New DejaGNU Release?

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