Jacob Bachmeyer <[email protected]> writes: > 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.
It's of course up to you, but it is unfortunate when distros have to rely on word-of-mouth or gut instinct when figuring out what to backport, and inconsistencies can arise between distributions too. Smaller releases with just bugfixes (even if just for an older series, or 1.6.3.1, or whatever) are convenient to quickly deploy while major changes need more testing before deployment. It's a shame if bug fixes (either minor but substantial in volume, or major) are held up on feature work unless they're linked. Anyway, you know all of that, but with distro hat on, I'd appreciate a release with bug fixes (-only, or minimal features, whatever is easier), and with upstream hat on, I'd appreciate a release so I can rely on some fixes in there rather than having to tell folks "your DejaGnu needs XYZ backported to make it work with Tcl 9" ;) > > 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. That sounds excellent. > > 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. > > [...] > > What does the list think of this plan and that option? > sam
signature.asc
Description: PGP signature
