bug fix release 2.4-1?

[jarioksa]

It may be that we should have a minor release 2.4-1 in September. For a while this looked necessary because R-devel commit 71113 on 18-Aug changed droplevels() behaviour so that betadisper() failed. However, the behaviour was again modified in commit 71129 ( 22-Aug) and old betadisper() again works. These changes are discussed in issues #192 and #193. New release is no longer absolutely necessary, but there are some glitches that could be fixed, and we could quite well have a September release. Here some points:

• Current CRAN tests with R-devel WARN on GNU extensions in Fortran files. I have now fixed all these warnings in cepin.f, decorana.f , monoMDS.f and ordering.f. None of these fixes changes the behaviour of these functions: they just remove the warnings.
• goodness.cca failed with rank=1 models and had lost choices argument. There were also some other glitches that needed fixes. These bugs were introduced with the complete re-writing of the function for the 2.4-0 release. Issues goodness.cca #189 and goodness.cca currently ignores choices argument #190.
• Checking problems in goodness.cca also radiated to fixes in some other functions with similar problem, and the work still continues here. Typical case is that we cast a vector to a diagonal matrix with diagmat <- diag(vec) which fails if vec has only one element (diag is one developer biting function that can take a scalar, a vector or a matrix as its first argument -- and works differently in all these cases). Other affected functions are stressplot.rda, stressplot.cca, fitted.dbrda, inertcomp, and the search continues. Function meandist also failed if the first or the last group had only one item (but worked if one-item groups were in other positions).
• as.mcmc.oecosimu failed when there is only one chain (that is, it usually fails). Function is rarely used, and the bug was introduced in 2.4-0 release when as.mcmc gained the ability to handle multiple chains.
• nestedbetajac and nestedbetasor did not cope with quantitative input data.
• although R again works with betadisper and other droplevels() utilizing functions, the fixes made improve robustness and should be published.
• In linestack with italic lables #195 we noted that a regression broke handling of expressions as labels in linestack(). The fix there should got to 2.4-1 (possibly with the extra change to add font argument to linestack() also).

In addition, there are some new features that could be safely ported:

• monoMDS gained points and text after a query in StackOverflow.
• diversity checks its input and works with NA (issue diveristy(): dealing with NA's #187).
• ordixyplot can draw polygons.
• tabasco is more configurable.
• There is a non-merged pull request Biplot scaling in cca/rda/capscale/dbrda #184 to change scaling of biplot arrows in rda and friends that Daniel Borcard requested for the next edition of their book.

[jarioksa]

Kurt Hornik approached us with this message on Sunday Aug-28, 2016:

Using gfortran with options -Wall -pedantic to compile your package
Fortran code finds important problems, see your package check pages for
more information.

Can you please fix these problems as quickly as possible?

This means that we need to release 2.4-1.

[gavinsimpson]

OK; how much of the above do you want to bring over to 2.4-1? That release could be just the gfortran fixes plus, perhaps, the droplevels fix. That could be done quickly I suppose. Then we'd roll the other stuff into a 2.5-0 release in a month or so.

Or do you want to go with the whole smash and bring in everything listed for a bug-fix release?

[jarioksa]

I'm a bit annoyed for this gfortran fix: it is plain pedantry. It has no user-visible effects but fixed and current functions work exactly in the same way. No user would see its effect -- I would not even write a NEWS entry on this. To have a release only for this reason is a bit silly.

There are several bug fixes, too. These are more important for the bug fix release because they touch users. Actually, only monoMDS points & text, polygons in ordixyplot, tabasco upgrade and biplot scaling in rda etc are new features that need not go to the bug fix release. I guess some could claim that biplot scaling is a bug fix, too, but I think it is a matter of taste.

[gavinsimpson]

Whoops, right. So shall we say 2.4-1 is everything in the first list above? The other stuff going to a 2.5-0 (which semantically would indicate new or changed behaviour). Or would you prefer to ship everything as 2.4-1. In which case, there is no reason that we have to have a 2.4-1 if we want to push out all the above; we could just call it 2.5-0?

[jarioksa]

I'm not mentally ready for releasing 2.5-0. All changes have been tiny or reactive so far. I needed some tiny features for a project in summer, and upgraded tabasco and ordixyplot, and then there are fixed after bug reports or small features after StackOverflow queries. I think 2.4-1 is OK by now. I'll have a look at things to merge.

[jarioksa]

I have merged all changes from the master except tabasco, ordixyplot and points/text for monoMDS. All others were plain fixes or improvement of documentation. There are two branches not yet merged to master that need consideration. I think`bp-scaling will not be merged, but issue-#193 perhaps should be merged -- it should first be merged to master (with its sub-branch of typo).

Monday 5 September 2016 will be the 15th anniversary of vegan: 1.0-1 was released on September 5, 2001.

[gavinsimpson]

I have merged the branch tracking changes for issue #193 (with the typo branch) into master, so that's ready for cherry picking.

We should add at least the fix for regression in expression handling in linestack (issue #195) (possibly after merging the branch adding font arg to linestack) to the 2.4-1 release. I'm adding it to the list at the top so it doesn't get missed.

[jarioksa]

I have fixed all but one type of warnings I get from Fortran: closing DO loops. Modern Fortran assume they are closed with END DO statement or numbered empty CONTINUE statement (CONTINUE does nothing in Fortran: it is only used as a placeholder). Old Fortran did not have END DO and using CONTINUE was for weenies and Pascal kiddies. Changing all these manually is scary: how do we know we did it all correctly? The decorana.f code gives 57 warnings on not using CONTINUE and I really do not like to start to modernize that legacy. I tried with two tools to programmatically change the legacy code to modern one, but correctly compiled (with obsolescence warnings) code failed compilation completely when "modernized". Bad tools. ordering.f has seven such warnings plus one on terminating nested loops in the same statements (which is completely legal and good style in FORTRAN 77). This is smaller task and could be done more easily.

I have followed the discussion in R-devel mailing list in hope of seeing that this is something that need not be touched. Several other package developer seem to have exactly the same DO issue with their legacy code. As usual, those making the decision in CRAN have been silent. So I really do not know what to do.

[jarioksa]

About legacy formats: all this is true. I know that DECORANA was written in punched cards and distributed as punched cards. Adding 57 redundant CONTINUE cards would have made the card deck 1 cm thicker and used more than one page of special coding sheets for punching. That is why it is called legacy software.

[jarioksa]

I submitted version 2.4-1 to CRAN a few minutes ago. Now we got to wait for the response.

The version fixed all Fortran issues -- including "obsolescent DO loop termination" that I fixed by hand. I hope this is not required in general. I had only 57 "obsolescent" loops in decorana.f, but legacy code can have much more, and more perverted (how do you know that a label is only used by DO loop and can be moved or replaced with END DO?). Today's R-devel also added a new test to see that all CRAN URLs are to https: that I also managed to fix.

[jarioksa]

version 2.4-1 is now in CRAN.