2.4.0 tag commit

[durack1]

@doutriaux1 @aashish24 might I suggest the following step-by-step is undertaken for 2.4.0 tagging? This should clear up some of the issues that have popped up with 2.2.0:

• Validate version info is correctly written (UV-CDAT version should be 2.4.0)
• Prepare and publish release notes (e.g. v2.2.0)
• Update dependencies so that checkout tag points are set and match 2.4.0 release: CMOR_BRANCH="uvcdat-2.4.0"; LIBCDMS_BRANCH="uvcdat-2.4.0"; VISTRAILS_BRANCH="uvcdat-2.4.0"; VTK_BRANCH="uvcdat-2.4.0"; UVCMETRICS_BRANCH="uvcdat-2.4.0"
• Update README.md with updated Stable version info (should be 2.4.0)
• Set 2.4.0 tag point for UV-CDAT/uvcdat repo
• Obtain Zenodo DOI
• Finalise README.md with updated Zenodo DOI info
• Move 2.4.0 tag point to new commit
• Update wiki so correct tag points (2.4.0) are noted for build notes: linux, MacOS X etc
• After 2.4.0 tag point set, reset all master checkout tag points to point back to uvcdat-master tags (PARAVIEW_BRANCH="uvcdat-master" etc)
• Increment uvcdat-master to 2.5.0 (odd minor [major.minor.patch] number indicating development version)

@doutriaux1 were there any other steps that aren't included above, if so please add/edit..

[aashish24]

@durack1 we need to update it with few more things but this is a good start. I will add my suggestion to it later today.

[durack1]

@aashish24 no problem, it would be great to clarify things properly so that there will be no need to move tags multiple times which just gets everyone confused.. If we set out a plan with a very defined step-by-step process, this can just be followed for each subsequent release..

[aashish24]

Sure 👍 Actually why don't we put it under the source code? Thoughts?

[durack1]

@aashish24 sure, that's another option - I just think having a step by step will ensure that the confusion of 2.2 and earlier tags isn't replicated

[aashish24]

@doutriaux1 can we tag 2.4 rc1 today?

[durack1]

@chaosphere2112 can you please re-run your release note scraper to produce the 2.4.0-rc1 equivalent of the 2.2.0 release notes?

[chaosphere2112]

Release notes available here.

[durack1]

@chaosphere2112 thanks for this!

[doutriaux1]

@chaosphere2112 gatekeeper tag should be ommited, it's really only for us it's fixed in a branch and should be closed.

[aashish24]

this is great. Instead of *** can we use "Others"

[aashish24]

Or something similar.

[durack1]

@chaosphere2112 can you recreate the release notes again please? It looks like there is some cleaning up to be done..

[doutriaux1]

@chaosphere2112 let's wait until it's tagged.

[durack1]

@aashish24 probably time to revisit the steps outlined at the top..

[aashish24]

• Validate version info is correctly written
• Prepare and publish release notes (e.g. v2.2.0)
• Update dependencies so that checkout tag points are set and match 2.4.0 release: PARAVIEW_BRANCH="uvcdat-2.4.0"; VISTRAILS_BRANCH="uvcdat-2.4.0"; VTK_BRANCH="uvcdat-2.4.0"; CMOR_BRANCH=uvcdat-2.4.0
• Update README.md with updated Stable version info (should be 2.4.0)
• Set 2.4.0 tag point for UV-CDAT/uvcdat repo
• Obtain Zenodo DOI
• Finalise README.md with updated Zenodo DOI info (and cleanup badges if required: check repo size it may not be working anymore)
• Move 2.4.0 tag point to new commit
• Update wiki so correct tag points (2.4.0) are noted for build notes: linux, MacOS X etc
• After 2.4.0 tag point set, reset all master checkout tag points to point back to uvcdat-master tags (PARAVIEW_BRANCH="uvcdat-master" etc)

I think these steps are good but missing

• Merge -s ours last release branch into master
• Create release branch off master
• Update master version to odd number

Yep I can edit - @durack1

[durack1]

@aashish24 feel free to rearrange this as you see fit (you should be able to edit your issue above - use the pen item in the top right corner of the issue box). The original intention was to outline ALL the steps one by one so that things are done once right, rather than previously when duplicate tag points confused folks for a while..

[durack1]

@chaosphere2112 I just had a peek at the latest version of the 2.4.0.rc3 release notes

A couple of these are incorrect, there have been multiple update hops since 2.2.0 was released (under Build):
Enhancement: Update cython to 0.22 -> should be 0.23.4
Enhancement: Update matplotlib to 1.4.3 -> should be 1.5.0
Enhancement: Update scipy to 0.16 -> should be 0.16.1

[durack1]

@chaosphere2112 @doutriaux1 @aashish24 some other missing issues/completed PRs to be added to the release notes:

#1635 - Update Vacumm 2.5.1 To 3.0.0
#1681 - Update R 3.2.1 To 3.2.2
#1683 - Update h5py 2.4.0 To 2.5.0
#1686 - Update Python Seawater 3.3.2 To 3.3.4

[chaosphere2112]

@durack1 I'll update the changelog as soon as I get in; my other laptop needs to get auth'd to the external network first.

[chaosphere2112]

As an added bit of usefulness with this release, this should go in the release notes: a list of the major new features in 2.4 as well as examples on how to use them.

https://github.com/UV-CDAT/uvcdat/wiki/2.4-Features-Documentation

[chaosphere2112]

@doutriaux1 @aashish24 @sankhesh Feel free to update that document as necessary; if you come up with new examples, I'll add them to the gallery.

[durack1]

@chaosphere2112 this is unreal - such "new features" will be a great addition to highlight in the release notes, and continue to build the documentation tree through time.. It's great we have all these new colormaps too! One very happy user here..

[chaosphere2112]

@durack1 Helped find a bunch of bugs, too!

[durack1]

@chaosphere2112 sorry to bug again about the release notes, but they don't seem to have grabbed the changes noted above here and here

[durack1]

@chaosphere2112 @doutriaux1 @dnadeau4 I think with the new colormap stuff noted above, you might be able to close #906 - take a peek and close if you think it's solved..

[chaosphere2112]

@durack1 I'm looking into that now.

[durack1]

@chaosphere2112 nope, it seems these still need tweaks - I think what is happening here is that:

Enhancement: Update cython to 0.22 -> 0.23.4 #1538 (I updated the issue title)
Enhancement: Update matplotlib to 1.4.3 -> 1.5.0 #1549
Enhancement: Update vacumm to source from github (2.5.1 -> 3.0.0) #1635 (I updated the issue title)
Enhancement: Update scipy to 0.16 -> 0.16.1, tweak to the next patch #1193 (I updated the issue title)

[durack1]

@chaosphere2112 I've just been peeking at the matplotlib available colormaps, and am wondering if creating a similar graphic to that found at: http://matplotlib.org/1.2.1/examples/pylab_examples/show_colormaps.html (linked below) which includes all the matplotlib and vcs colormaps wouldn't be a good idea?

>>> import matplotlib
>>> print matplotlib.__version__
1.5.0
>>> import matplotlib.pyplot as plt
>>> maps = sorted(m for m in plt.cm.datad if not m.endswith("_r"))
>>> for count,a in enumerate(maps):
...  print a

Yields 72 colormaps alone, then add the VCS ones! It'd be nice to expose all these and document it somewhere.. And would also then provide an opportunity for clipping, if many duplicates exist

[chaosphere2112]

@durack1 Yeah, that's a good idea. I'll get something thrown together tomorrow.

[durack1]

@chaosphere2112 this might be an even more up-to-date page to base off - it includes the viridis (perceptually uniform) colormap that alot of effort was put into and also here.. I'm not sure where these colormaps are hiding (they are not included in the list generated above), but the clues are in the sample code linked above..

[durack1]

@chaosphere2112 some new palettes can be found at: https://github.com/durack1/pylib/blob/master/colourLib.py

Sorry I took so long, these were in pretty bad shape and the conversion took longer than I thought..

[chaosphere2112]

@durack1 OK, I'll take a look through these tomorrow (once I finish up our UV-CDAT poster for the F2F).

[durack1]

@chaosphere2112 no time stress.. If they make it into 2.4.0 that would be great, if not I'll make do with master..

[chaosphere2112]

@durack1 I believe I've written the code needed to import your colormaps (were they in blue, green, red?). Some of them looks slightly redundant; this chart is matplotlib on the top, VCS on the bottom left, and yours on the bottom right. Are there any in particular that you think the community would benefit from? Also, I can give you the code I used to convert them into VCS if you want it for your own usage.

[durack1]

@chaosphere2112 excellent, thanks for this!

You're right there is some redundancy, however the subtle differences with my palettes that are harder to ascertain are the exclusion of a white (or grey) separator between halves of the color scales.. Now that we have all the palettes to peruse it could be a good idea to trim the redundant/duplicated ones..

I also wonder if you've managed to grab all the latest matplotlib colormaps - as I don't see the viridis palette displayed above.. From my perusal, it seemed those new palettes are stored in some new format/location that is separate from the previous to 1.5.0 releases..

[chaosphere2112]

Yup, I'm looking into that now

[durack1]

@chaosphere2112 to be honest I'd wonder whether some of mine are _r (or matplotlib notation of reversed) versions of one another.. I didn't do a flipped comparison - for e.g. temp1 == rain1_r == wind1? Are these identical?

[chaosphere2112]

I'll take a look and see! May well be. Hm... it might be handy to add a flag to colormap objects to flip them, so we can easily have _r maps without cluttering the colormap namespace.

[durack1]

@chaosphere2112 yeah, I think it's redundant to have two numerically identical (but flipped) palettes stored - so having the ability to reverse these (so in some cases, from red -> blue to blue -> red) is a really nice feature.. It'd be great to have that built into the VCS palette objects..

[chaosphere2112]

@durack1 Looks like rain1 is the reverse of temp1 and rain2 is the reverse of temp2. wind1 has a couple of more values than rain1, but I'm doing a linear interpolation to expand the colormap range to 256, at which point they're basically identical. I think I'm going to punt on adding these till after the release, and add the colormap reversal attribute at that point as well.

[durack1]

@aashish24 @doutriaux1 just wondering if the 2.4.0 release page (congrats BTW) is going to be updated like the previous 2.2.0 release page - the google docs working document would make this a 2 minute job (assuming all the links are in place).

[aashish24]

@durack1 yes, it will, I am in the process of it. Should be done tonight/tomorrow.

[chaosphere2112]

@durack1 @aashish24 @doutriaux1 I'm updating the changelog and I'll merge in my two 2.4 branches for the website, so my links will be in place shortly.

[durack1]

@chaosphere2112, it seems the release notes still need tweaks, we're a bit behind on the patch updates that aren't up-to-date to what's in 2.4.0:

Enhancement: Update cython to 0.22 -> 0.23.4 #1538 (I updated the issue title)
Enhancement: Update matplotlib to 1.4.3 -> 1.5.0 #1549

[sankhesh]

@chaosphere2112 Could you please push those release notes to the Github Wiki to replace 2.4.0RC3 Release Notes page?

[doutriaux1]

Released!

[doutriaux1]

@chaosphere2112 if you would happen to have the code handy it would be great. Otherwise don't worry I can rewrite it in 15mn. Thx

[chaosphere2112]

That color map code? Long gone, I'm afraid. Did @durack1 finally get this onto your list 😆?

[durack1]

@chaosphere2112, who says persistence doesn't pay?!

[doutriaux1]

no worries @chaosphere2112, it's a 15mn job top.