Closed slayoo closed 4 years ago
What is your time scale? If not too short, we should get #468 in -- Python 2 get EOL at the end of the year, so we should have Python 3 support before.
BTW, you can create a milestone to trace what has to be done until the new release. https://help.github.com/en/articles/creating-and-editing-milestones-for-issues-and-pull-requests That is very convenient and allows the public to follow (and to concentrate on those).
Hi, I'm goind to merge most of the PRs soon, and #468 is top of list. #629 will probably have to be done first since it brings visible speedups and reduced concurrent compilation time (but there is an issue with the python part, normal as I do not usually test python). Many of the others will follow, especially #625 which makes a real difference for the future new release. I would say the milestone is getting rid of all those PRs and that's it.
STATIC METHODS
Seems to be one achievable feature that may be within the scope of the code structure.
Hopefully an icon for GDL can be supplied together with the gdl.desktop file, so people can find/launch it in a graphical enviornment.
feel free to use this one: http://bootes.ethz.ch/gdl4.png (there'x also 1..3, and the .xcf gimp files)
Yes, it would be great to have a new release ! Do you already have a version number in mind ? 0.9.10 or 1.0.0 ?!
On my side, what we have to do before :
Do you already have a version number in mind ? 0.9.10 or 1.0.0 ?!
Perhaps 1.0.0-rc1?
Why not. May be @olebole could help us following Debian rules ? thanks
What rules do you mean? Debian can adopt a lot of rules ;-) I would recommend
1.0.0rc (or similar) should IMO only be used as the "release candidate" for 1.0; and it should be followed by 1.0.0 after a few weeks (unless the RC has some serious problems that need longer to be fixed).
A version 1.0.0 is however a good chance to make some advertising: to announce it on Facebook and Twitter etc. that could push the usage. Therefore I would not recommend to "just" make a 1.0 release.
Well, that was not about Debian rules …
If I may, indeed a 1.0rc would be great. In retrospect, there are a few bugs still in the map_* procedures, so some projections give gorgeous maps and other give terrible results. (difficult to cope with 150+ projections!). Please do not wait for me, it will be the subject of another release.
I'll then put together the release notes today
Here's a draft of release notes - let me know if anything needs to be added:
- entirely rewritten mapping support (thank to Gilles Duvert)
- major improvements on the Windows compatibility (thanks to Greg Jung and Gilles Duvert)
- shift to Python 3 (thanks to Orion Poplawski and Ole Streicher)
- added READ_CVS, SCOPE_VARNAME
- fixes in CONGRID, FILE_MKDIR, FX_ROOT, INTRPOLATE, LINFIT, MAKE_ARRAY, RESTORE, TAG_NAMES, ...
- numerous other fixes and performance improvements and increased test coverage
If not, I'll:
Re @olebole comments on the "rc" suffix - I think that "it should be followed by 1.0.0 after a few weeks (unless the RC has some serious problems that need longer to be fixed)" is correct.
Anything else needs to be done?
I made some extensive benchmarkings on three different computers (4, 16 (OSX), 48 cores) and the results are good :)
I hope to deliver the files & figures in the middle of the week (I need to complete few cases with FL)
Prepare some PR? I could advertise it with a twitter post from@DebianAstro, but IMO there should be a bit more.The Facebook Astronomy groups f.e., some mailing lists etc. My experience is that people often still have some negative experiences with old versions, so there should really something what was achieved.
Here it is: https://github.com/gnudatalanguage/gdl/releases/tag/v1.0.0-rc.1
Closing, please report any issues with the release in separate issues
@olebole please spread the word! @gdlpackagers - new release! please spread the code!
@gnudatalanguage/gdlmaintainers @gnudatalanguage/gdlpackagers Please post here comments on what should be done before making a new release?