Creating A Release and Versioning about bsc HOT 9 CLOSED

I want to create a branch/tag for BSC v4.0.0 soon, but there are some cleanups that we'd like to get in first. (For example, if we're going to make changes to the installation layout, as in issue #85 , then we should do that now.) When that's in place, we can make pre-built versions available here on GitHub (via the "releases" tab) and it can be packaged and distributed elsewhere. Hopefully that will satisfy the immediate need, while we decide the process for when/how next versions are branched/tagged.

from bsc.

It has taken a long time, but I hope that we can now close this issue, with the release of BSC 2021.07?

@BracketMaster , I appreciate that you filed this and I apologize that it has taken so long! If you are still offering to maintain packaging for homebrew (or any other system) that would be appreciated. I'd like to see BSC available in more package systems, now that we have versioning.

The release page also has pre-built tar-files for download. And I believe this should make it easier for CI environments to download a known binary distribution, and not have to build from source.

Since my earlier comment, there have been some changes. The date field has been removed. And the interpretation of the version string as three fields has been removed, allowing it to be a string of any form. And that string is no longer hardcoded in Version.hs but is instead auto-generated by the update-build-version.sh script.

When run inside a Git repo, the script will use git describe --tags to produce the version string. If the current commit is tagged, then that will be the version string. So building from the 2021.07 tag will result a BSC with that version. If you build from a later commit, you get 2021.07-g<hash>. There is also support for building from an exported snapshot, outside of Git.

from bsc.

BSC will show the version like this:

Bluespec Compiler, version 2017.07.A (build 0b249fb2a, 2017-07-21)

but will omit the version name and the date if those fields are empty, which is why you only see the git commit at the moment. The version name and date are defined in src/comp/Version.hs.

These fields are empty because we don't yet have a system for versions and releases. I would very much like to have that, though.

Bluespec switched to using a YYYY.MM.TAG format, similar to how some other commercial EDA releases are versioned. But before that, the numbering was 3.8.#. We could start versioning the open BSC at 4.0 or 5.0. But first I want to fix a few behavior differences that have accidentally creeped into this code, and I'm first working on publishing a test suite.

from bsc.

Awesome. I've almost got a bsc ready to push into homebrew.
Just tell me what version number I should use - right now I have it set to 0.0 in homebrew, and am setting the package name to bsc

Does this sound good?

I set 0.0 Because I imagine you'll want to update the version number later...

from bsc.

I'd be excited about a release too, so that we could just download that in our CI instead of building it from source each time our CI runs.

from bsc.

I'd be excited about a release too, so that we could just download that in our CI instead of building it from source each time our CI runs.

#147 could alleviate the problem for CI until a release happens. And after a release happens, it is just a matter of tagging versions.

from bsc.

Also note that the CI does create artifacts that are available after it has run. Prebuilt releases from the HEAD (as of this post) are available here for Ubuntu 18.04, Ubuntu 16.04, and macOS 10.13+ (tested on 10.15).

from bsc.

Also note that the CI does create artifacts that are available after it has run. Prebuilt releases from the HEAD (as of this post) are available here for Ubuntu 18.04, Ubuntu 16.04, and macOS 10.13+ (tested on 10.15).

It's nice to have these artifacts, but GitHub does not want people to download them programmatically: You can only download them if you're logged into your GitHub account, as far as I can tell, and therefore I think a CI script would not be able to use them.

from bsc.

Thanks for following up on this. I can look into this next week, seeing if it can build on homebrew without any issues.

from bsc.