Checklist for v2.0.x release

[kdahlquist]

I occurred to me as I closed a bunch of issues tonight, that we should start documenting the features and bug fixes going into the new release.

Maybe it's time to start a draft release for this (or maybe not). In either case, our aim is to do a release by the end of the last week of class, i.e., April 28.

I'm assigning this one to @NAnguiano and @anuvarsh (our graduating seniors) to do the honors, but everyone on the team will contribute his/her new features/bug fixes/tests to this. At our next meeting on Thursday, I will ask each team member to commit to what s/he will have done for the end-of-semester release.

Within this issue, let's keep a tally of all the resolved issues that are going into this release, organized by feature/bug fix/test suite.

This will aid us in getting the Documentation page of the website ready for the new release as well because we are changing the way the GRNsight behaves in some ways and adding new features.

[kdahlquist]

I realized that we can't really start the draft release until we are ready because one of the first steps is tagging the release. So, I renamed the issue. I'm pasting the release checklist here so we can check items off when it does come time to release.

However, since we have not had a master release since August, there are a lot of new features/bug fixes to document. I'm going to start the release notes as comments to this issue. We also need to be thinking about what needs to be changed in the documentation.

• In the days leading up to the release, all open issues that need to be resolved before the release will be given the label "for next release".
• Merge the branch(es) under development into master
  • Resolve any version control conflicts
  • Test the final merged version
  • Perform hotfixes on master as needed
• Tag the final, tested version as v#.#.# (all three numbers are required, even if 0; see npm step below)
  • Remember that the tag needs to be pushed to GitHub: git push origin <tag-name>
• Create draft release item on Github repository (name it exactly like the tag)
  • Make release notes: a list of new features/bug fixes with issue numbers covered by this release. Note that this at least will be the ones labeled "for next release", with possible others.
• Publish GitHub release item
• Publish release to GRNsight home page
  • Update the version number and modification date on gh-pages
• Increment beta version
  • Merge released master with beta, especially if hotfixes/merges were made on master
  • Update version number and modified date on gh-pages
• Publish to npm
  • Update version numbers in all package.json files
  • npm requires all .0s in the semantic version
  • Check to see that BioJS updates its GRNsight entry
• Run Istanbul and note new test coverages (optional)
• Update the About page with release notes (GitHub release item without issue numbers)
  • Update the browser version compatibility statement with the latest version of Chrome and Firefox for which the new GRNsight version has been tested.
  • Update modification date
• Add news item about the release to the News page
  • Update modification date
  • Link news item to the corresponding release notes in the About page
• Update Documentation page with any new features or updates to old features
• Update README.md at top-level directory of master branch, if necessary
• Update version number/other relevant information at current bioinformatics listing sites
  • Elixir
    • Then change hyperlink on the GRNsight Links page, if necessary
• Get DOI for new release from Zenodo
  • get badge and include in README.md at top level of repo
  • update CITATION.md file with DOI (and badge?) for the new release
  • update "How to cite GRNsight" section on About page

[kdahlquist]

I updated the checklist in the comment above with revisions to the Release Procedure documented in issue #429 and #440.

[kdahlquist]

As promised, starting the release notes here (updated 5/4/17 by @kdahlquist with current feature set).

GRNsight v2.0.x includes the following new features and bug fixes:

• When a weighted graph is loaded, the user now has the options to show weights upon mouseover of an edge, always show weights, or never show weights Option for showing or hiding all weights #285
• The bounding box and viewport for the graph have been separated allowing for the following new features:
  • The bounding box can now be fixed to the size of the viewport or adapted to the size of the graph Implement preference for hard or adaptive drafting board size #396, Implement adaptive drafting board resizing algorithm #398
  • The viewport size can be selected from among small, medium, and large options Create an option to have a small, medium, and large bounding box for different sized screens #159, Implement preference to change viewport size between small, medium, large #397
  • The best viewport size is automatically detected from the browser Implement automatic discovery of initial drafting board and viewport size #395
  • The viewport can be fit to the size of the browser window Changes to UI to support new features #411
  • Zooming and scrolling have been enabled Make bounding box/zoom/scrolling/size toggle-able #345, Implement viewport scrolling and drafting board scaling #399
• Improvements to visuals have been made, including:
  • Reducing the white space on either side of a node label for long labels Reduce white space one either side of gene label #333
  • Setting the minimum size of a node Reduce white space one either side of gene label #333
  • Making the pointed arrowhead larger for the thinnest edges Make the arrowheads larger for unweighted and thinnest weighted edges: fix tips going behind nodes #392
  • Minor adjustments to the placement and centering of edge end-markers Blunt markers are not centered especially for thick edges #188
• The use of special characters (except for "-" and "_") in node labels are no longer supported due to integration of cytoscape.js code into GRNsight for future implementation of graph statistics feature Create a warning for Cytoscape Graph Statistics Report Failure #343
• "Under the hood":
  • The versions of package dependencies have been standardized and documented in the package.json file npm packages not currently on package.json #334, Update package.json file so that versions are fixed, not "latest" #383
  • Code has been ported to version v0.7.2 of Node-xlsx Port GRNsight code to latest node-xlsx implementation #204
  • Testing suite has been refactored into semantic and syntactic tests Refactor server code to facilitate error checking on multiple formats #300, Clean-up the test suite #335, Semantic checker needs to be integrated into SIF and GraphML importers #386
  • Additional syntactic tests have been written for SIF (Add "syntactic" tests for SIF format #362) format
  • A catch-all syntactic error has been implemented for ill-formed GraphML files so that the server doesn't crash upon loading (Add "syntactic" tests for graphml format #363)
  • A cap has been placed on the number of errors returned according to a tunable strictness parameter Handling of extraneous data in test suite using strictness parameter #339
• Numerous bugs have been fixed Clean-up the test suite #335, Beta is giving 502 (Bad Gateway) on demos and uploads #337, Create test(s) for out-of-memory error caused by some files #340, Reload is not functioning on beta #347, Slider Display Values do not change after loading a file #364, Semantic Checker Throws Errors On Loading a Graph #408, Don't show Edge Weight Options when an unweighted graph is loaded #419, Beta v2.0.9 crashed when reviewing #362 #450, SIF importer crashing due to "entry" being null #451, Reset sliders and undo reset slider menu options are not working in beta (buttons are still OK) #454

[kdahlquist]

@dondi says "Don't be afraid of merging". Since master hasn't been touched (except for the documents folder), this should be straightforward.

@anuvarsh's work on the normalization won't be included in this release and has been moved to a normalization branch #264. @NAnguiano, you just need to hide the UI controls for this.

@dondi and @kdahlquist agree that @NAnguiano should finish her finals for her other classes before returning to this. Our new target for a release is Monday, May 8. The last hard deadline for a release is Wednesday, May 10 at 5:00 PM PDT.

[kdahlquist]

What is the status of the release?

[NAnguiano]

Doing final bug testing just to make sure there's no major bugs. Should be up within an hour :)

[NAnguiano]

PR is up. Release procedure will be followed as soon as it's pulled in.

[NAnguiano]

With the merging of PR #483, am I good to go to start pushing everything into master? I updated beta with the newest version, so I'm not sure if external testing is wanted first.

Also, I found this in the logs when I went to refresh the server... I don't know if it means anything, but it seemed a little weird to me.

[NAnguiano]

What version number will this release be? v2.1.0?

[NAnguiano]

So I was about to go ahead and just merge and do the release (I'm impatient) when I realized... I don't actually have access to master. I can't update it myself - I only have access to beta.

I think @anuvarsh and @dondi have master access. So... I think either I'd need one of them around when I go to do the release. Right now, all I could do is just merge it into master, but I couldn't actually make it go live.

I can't believe I didn't think of this beforehand, but yeah. I can't actually make the new release go live. Oops! 😅

[dondi]

Hi, yes, sorry, I’ve been in grading hell (limbo?) most of today after I did your code review (which was sort of a break for me). My quick answer for now is that I think it would be useful to have a round of QA simply because of how many variations this latest slate of changes can involve.

Second, that screenshot is interesting…looks like someone is trying to hack our server. Might not be directly their fault; they themselves could have bit hit by a cross-site script. The good news is that our server pretty much just ignored those requests. In case you didn't already know this, the .ru top-level domain is…Russia.

So hang tight…grades are due Wednesday so there should be more exhale time by then…

[NAnguiano]

Sounds good to me! And hmm.. That's.. interesting. Well, good to note at the very least.

@dondi @kdahlquist Stay strong - grading is almost over!

[kdahlquist]

I'm back online again and will poke around on the new beta now. My feeling about the version number is this:

1. It seems kind of weird to me that our first master release would be 2.1 instead of 2.0, so I'm leaning toward 2.0.x, like 2.0.19, if we end up making the current beta the master.
2. I don't see any reason to worry about "odd" and "even" numbers now that we are using semantic versioning with 3 numbers. Hot fixes to master would increment 2.0.19 to 2.0.20, etc., and the new beta would start out at 2.1.0. When that is released, master would become 2.1.x+1, and beta would then be 2.2.0 and so on.

Any objections to this?

[kdahlquist]

I've played around with beta some (not exhaustively) and nothing that I've tried has crashed the graph (or the server). I think we're OK to go ahead and do the release.

[NAnguiano]

Sounds good. I still don't have permission to update master, but I can do the merge at the very least and update what I can. Someone will just have to tell me when master is updated, so the version number on the website can be changed.

[NAnguiano]

The draft release is completed, master is merged and tagged.

Unfortunately, until master is actually updated on the live site, I'm not sure I can go much further. There will be a series of changes that will need to be made to gh-pages so that master appears correctly. I have them locally made already, but they also break the current master, so I can't quite push them until master is up to date. I'm changing documentation and such locally as well so that's ready to push once master is up to date.

I've already gone ahead and merged master and beta, then incremented the beta version.

[NAnguiano]

The documentation, news, and about pages are updated on my local version. All the gh-pages changes will come out as soon as master is updated, because it doesn't quite make sense to me for the documentation to be reflecting changes that haven't been made live yet.

[kdahlquist]

That all sounds good. We'll just have to wait for @dondi. He'll probably come up for air soon.

[dondi]

Ah yes, coming up for air is right, but oh what a feeling!

I’ve merged beta into master. I had to delete/re-add the v2.0.20 tag since the merge created a new commit. Other than that, I think we can proceed with our checklist. Looks like we got a little bit ahead of ourselves there, with the master-merging items already checked off. I unchecked the “Test the final merged version” and “Perform hotfixes on master as needed” as I think those would be the next steps now that beta has been merged with master.

I’ll be detoxing a bit for now and can come back to this in the afternoon for next steps.

[NAnguiano]

I had merged beta and master yesterday, which is why that was checked off. There aren't any new changes to pull, so it looks like everything went well? I tested it out when I did the initial merge, and everything looks fine, but ultimately it's hard to test everything until it's live.

@dondi when you get a chance, can you update the live master screens? I've got all of the changes to gh-pages ready locally. But I don't have permission to update the master screens - only the beta ones. So the changes to gh-pages will be ready for push as soon as master is updated on the GRNsight website.

[dondi]

Ohhhh, it was that master you were referring to, not the GitHub branch. OK, it’s up now. I had to run things the “old” way because nodemon would fire up node rather than nodejs. Did you do anything differently? I looked around for alternative configurations or command-line parameters but didn’t find any. If you have a different way for starting things up, let me know.

[kdahlquist]

Just a quick request--can we just put the last modified date and not the time on the web pages? I'm not sure when that crept in, but I think the data alone should suffice.

[dondi]

The date is indeed the norm; I have only added the time when the prior update had taken place on the same day (to indicate that it was indeed update). This looks like a vestige of when we were making multiple updates in the same day, to help us verify that something was indeed changed.

Definitely this time we can stick with just the date.

[NAnguiano]

On the server, beta and master are run almost exactly the same way as before. I think I mentioned it on the issue where the npm start stuff was initially mentioned, but I didn't write it formally anywhere. I'm not sure where I'd put it, but I'll look for a good spot...

For example, on beta, this is the current command to run web-client:

NODE_ENV=beta nodejs web-client/app.js

So almost the same as before, but instead of cd'ing into the web-client directory and running it there, you run it from the parent directory and type in web-client/app.js instead of just app.js.

Both server and web-client will have to be run this way. The nodemon stuff doesn't work with the servers, so it has to be done this way. Makes sense to do it that way anyways, since it won't be updating too often and it's pretty easy to just restart it.

Note that it won't work properly if it's not run using commands like the one above.

[NAnguiano]

GRNsight v2.0.20 has officially been released! The updates to the documentation, news, and about page are live, the version number is updated, and the release has been published to Github. 😄

@dondi I updated the commands on the server setup wiki page so they're accurate now.

I'm not sure how to go about doing things like publishing to npm or the Zenodo stuff. But I've done everything that's currently checked off above.

[kdahlquist]

Congratulations! I'll look into the Zenodo stuff et al. when I get back next week!

[dondi]

npm publish has been done: https://www.npmjs.com/package/grnsight

…and picked up by BioJS within minutes: http://biojs.io/d/grnsight

[dondi]

Looking at our master README.md, it looks like the main desirable change is an update to our personnel. But there may be more; we can coordinate with @kdahlquist on this when she gets back.

Now that I think about it, perhaps the step for updating the README.md should precede the release. This way, the latest README.md is included in the tagged release version. I’ll update the wiki to inform future releases.

[dondi]

Test coverage statistics for v2.0.20:

Statements   : 69.96% ( 368/526 )
Branches     : 83.12% ( 192/231 )
Functions    : 61.39% ( 62/101 )
Lines        : 69.9% ( 367/525 )

[kdahlquist]

Made an issue #488 for @dondi to check to see if Zenodo gave us a DOI for our release.

[dondi]

DOI, Elixir, and website updates have been made. I think this can be closed after a review.

[kdahlquist]

I reviewed the checklist. I will probably make minor wording changes to the website, but that's a separate issue, e.g. #418. I'm going to make a few changes to the top level README as well, but I'll make that a separate issue.

Putting this one to bed--Goodnight!