Release version 2.4.0

[edwardhartnett]

1. Update issues/projects.
2. Update VERSION file.
3. Build docs and put them on gh-pages branch.
4. Edit release notes.
5. Do release on GitHub.
6. Draft next version release notes and start next version project if needed.
7. Update spack main repo with new release.

[edwardhartnett]

@AlexanderRichert-NOAA why don't you do the documentation for the next release.

The documentation is served up by the gh-pages branch, a weird little feature of GitHub. Read more about it here if you are unfamiliar: https://docs.github.com/en/pages/getting-started-with-github-pages/creating-a-github-pages-site

What's somewhat tricky here is that we also want to accomplish this issue: #65.

What you need to do is:

• On gh-pages branch, create directory v3.3.3.
• Use git mv to move all existing documentation on the gh-pages branch to the v3.3.3 directory.
• Build the new version of the docs and add them to the gh-pages branch.
• Put something in docs/user_guide.md to refer to old documentation. See https://noaa-emc.github.io/NCEPLIBS-g2/ for an example - do it just like that.

Once you are done, just like the g2 docs, we should have the new docs up and the old docs available in a subdirectory.

Let me know if you have any questions.

[AlexanderRichert-NOAA]

@edwardhartnett Sounds good, I'll have a go at this momentarily. Question about that third step: Is that a manual process? Like, build the v2.4.0 docs on my machine then copy over, or is there a slicker way to do that?

[edwardhartnett]

I just clone two copies of the repo. One I use to build the docs. The other I switch to gh-pages. Then I cp -R html/* from the doc build to the gh-pages one, and git add *.

[AlexanderRichert-NOAA]

@edwardhartnett Can you elaborate on what's involved in editing release notes? (at least I think that's what comes next)

[edwardhartnett]

Yes, just go to the releases page on github and update the list of "New in this Release".

I do this by scanning the list of issues resolved in the release (on the project page) and mention the important ones, and categorize others, see some release notes for details.

When editing release notes it's important to his the "save as draft" button at the bottom, instead of "release", which will cause the release to happen. Basically, just don't accidentally release before you are ready. It's easy to do that, editing the release notes.

The release notes should contain a link to the project page, so users can see the complete list of issues resolved. So it's not necessary to mention every one in the release notes. But I generally find a way to do so.

I've already updated the release notes for this release. Take a look and see if there's anything to add.

[edwardhartnett]

Also we will wait for these releases on Rahul's iteration of the shared/static cmake stuff. He may find a way to make it better or more compact, and that will be handy because I believe we will then apply it to all our libraries and do releases. So we might as well make sure it's the best possible solution before applying it everywhere...

[edwardhartnett]

OK, looks like after we merge #101 we can do a release...

[AlexanderRichert-NOAA]

@edwardhartnett Just updated release notes, I don't think there's too much that needs to change. Once I'm sure that we're happy re: #81 then I think we're good to do the release and update spack.