Is it time for release 13?

[caryr]

A large number of changes have gone into the repo since out last release almost a year ago, so I believe it is time to start thinking about a V13 release.

I'm currently working on fixing a VPI issue #1038 and there is one more I would like to look at and fix if possible #1041. Are there any other bugs or enhancements people are working on that they would like to get into the repo before a new release?I'm trying to focus on bugs with the limited time I have right now. Also if someone else wants to look at #1041 that would just make it easier.

@steveicarus do you have time to roll a release once we decide it is completed? Hopefully in no more than a couple weeks.

I hope everyone is doing well. Take care, Cary

[martinwhitaker]

I say go for a release. I don't think any of the open bugs are serious enough to delay it.

I did have a quick look at #1041. I think the problem is that vpi_put_value sends the value to the output of the net, whereas it needs to send it to the input. I may have some free time this weekend to work on it.

[steveicarus]

I agree, this is a good time for a new release. I have removed the release specific bits from the ivtest suite, so releases should be even easier now.

[caryr]

I think once the tests were integrated into the repo the TB was then synced. The recent removals is mostly getting ride of cruft that no longer serves a purpose, but does not impact a release.

[caryr]

One other thing that should be synced is the list of constructs not supported is incorrect in the local documentation. This had been updated on the external web page, but those changes never made it back into the repo documentation. We probably should do a pass over the entire documentation set to make sure things are as expected before the release.

I'm going to try to finish #1038 this weekend and I need to look at the algorithm for time rounding in the context of my recent FreeBSD fix since it is numerically very unstable if being off by a single bit in the pow() function causes a test failure.

[steveicarus]

It does, since creating a new release would have required creating a ne regression-<N>.list. That file was selected automatically. And yes, lots of cruft was also cleaned out.

…

On Thu, Jan 4, 2024 at 9:39 AM Cary R. ***@***.***> wrote: I think once the tests were integrated into the repo the TB was then synced. The recent removals is mostly getting ride of cruft that no longer serves a purpose, but does not impact a release. — Reply to this email directly, view it on GitHub <#1058 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACKMXT7M77CAC5FEYZ2ETYM3SNFAVCNFSM6AAAAABBG4YEVKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DAMJVGQ3TG> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Steve Williams ***@***.*** ***@***.***>

[caryr]

Ah, yes.

[gatk555]

A newcomer here, so feel free to ignore me. I think I have a modified version of #667 that is ready to become a replacement PR. But there is no demonstrated use case, as that was blocked by #1041. It seems that there may now be progress on this, so for me it would be nice if there was time to validate #667 and have it considered for the next release. On the other hand #667 rearranges fundamental code in vvp and I would completely understand the response "That needs to simmer for months before being considered for release."

The only reason this might matter is that my application is intended as a new feature in mixed-signal simulator ngspice (like this). Ngspice typically has three releases a year (with one last week). So if "vvp as shared library" misses the boat, I will have to remember to remove "a development build of iverilog must be used" from the Ngspice manual, a year or two from now.

Thanks,
G.

[caryr]

In general if you can completely articulate the changes you are making, why they are correct and the test suite passes we do not usually require a simmering period.

[martinwhitaker]

I see there is currently one unexpected failure in the vlog95 target tests.

[caryr]

Yes, it is related to the changes done for SDF support. I've not looked into if this is a bug in the compiler or a limitation in the vlog95 code generator.

[martinwhitaker]

Time is slipping by. It would be good to get a new release out soon.

[caryr]

I hope to have some time in a week or two to finish the task I was trying to get done for the release. My hectic day job is getting in the way of all the Icarus fun.

[martinwhitaker]

As we still haven't made a release, I'm minded to at least create a snapshot. However, now we are publishing on GitHub instead of icarus.com, there is a new problem. Previously Steve would include a suitable version_tag.h in the source code tarballs. But GitHub releases are created directly from git tags, so we would need to commit the file in git. But that file is in the git ignore list because it is normally automatically generated using git-describe. So I propose adding another file, release_tag.h, which becomes the fallback when neither git nor version_tag.h is present. That file would normally contain an empty string, but could be modified just before tagging a snapshot or a release then reverted back immediately afterwards.

It would be nice if that process could be automated, but I don't know a way to do it.

[caryr]

I've been thinking about a snapshot as well. Is there some kind of github action we can do to create the version information, build the gperf files, etc. and then tar all that up? I would assume other repos have some way to deal with this so maybe we need to do a little research before adding another file repo.

[martinwhitaker]

I already did some research. AFAICT, it's possible to use github actions to create additional binary files that are published with the release (which could include a source code tarball), but I don't see any way to hide the automatically-generated source code bundles (tgz and zip) which are generated directly from a tagged git commit (I think they are generated on demand, not at the point of release). I'll be happy to be proved wrong though.

We could use github actions to generate tarballs that are published elsewhere, but I think it would be best to publish them as github releases - that's where users will look for them.

[martinwhitaker]

P.S. I still think we should just go ahead and release v13. There will always be open bugs. Provided they aren't regressions from the previous release, they should not be a release blocker.

[caryr]

At this point I'm okay releasing v13. I would say it looks like work may not be so overwhelming soon so I can take care of the things I wanted for V13, but I've been proven wrong too many times to continue holding up the release.

[AssassinK786]

Any Update when windows version of iverilog will be released?

[martinwhitaker]

I have created two new scripts in the scripts directory, CREATE_SNAPSHOT.sh and CREATE_RELEASE.sh, which handle updating version_base.h and verilog.spec, temporarily create a release_tag.h, create the git tag, and finally delete the release_tag.h. Following this, you can just use git push --follow-tags to make the new tag available on GitHub, which means GitHub can automatically create tarballs on demand. I've done this to create a snapshot today. Should we publish this as a release (in the GitHub sense)?

[caryr]

One thing we have normally done is run autoconf.sh for all the released tar files to help reduce the dependencies needed to build iverilog. I've not discovered how to create an action that does this before/while creating the tar file. For SourceForge and the icarus site when it existed this is a manual step, but since github is automatic we should try to figure that out. At the moment the tar files on github require extra steps and that's not optimal. I suppose we could update the dependencies and documentation to require the extra steps for all, but these are steps we should ideally run if possible.

I have two issues I am working on that are fairly close to being completed so would prefer for them to be included assuming I can complete them before I get busy again.

I'll look at the script later, but they sound useful. Thanks!

[martinwhitaker]

I thought we had already updated the build instructions to include the extra step, but on checking I find that it was only for building from git. I think the only solution is to do the same as I did for release_tag.h - temporarily add the files to git and remove them in the post-release cleanup. This could be added to the scripts.

[martinwhitaker]

OK, I've updated the scripts to run autoconf.sh and temporarily add the resulting configure and lexor_keywords.cc files to the repository so they will be included in the tarballs generated by GitHub. The post-release cleanup removes them again as we don't want them included when working from git.

I won't create a new snapshot until you are happy with this.