The download link for the source tarball of BiocInstaller 1.16.3, which is part of the 3.0 release, at http://bioconductor.org/packages/3.0/bioc/html/BiocInstaller.html is broken:
http://bioconductor.org/packages/3.0/bioc/src/contrib/BiocInstaller_1.16.3.tar.gz
Is this a temporary issue?
Are there any alternative download locations?
This is fixed, or will be in a few minutes. However, you should install BiocInstaller from R, not from the web, with this command:
source("http://bioconductor.org/biocLite.R")
Thanks for the info.
We prefer to be in control over which versions get installed, which is why we download the source tarball ourselves.
Disappearing versions (like version BiocInstaller 1.16.2, which was included in the Bioconductor 3.0 'release' at some point, and now is *nowhere* to be found) makes this very painful though...
So, the way to fix this was to bump the BiocInstaller version to 1.16.5? Is 1.16.3 still available anywhere?
Some people want to be able to exactly reproduce a setup they had before, making source tarballs disappear makes this impossible...
What's the reasoning behind this? I've heard people say stuff like "the previous version contained bugs". That's a valid statement, most likely, since it basically applies to *all* versions that are released. Bugfree software simply doesn't exist.
The release versions of packages are only supposed to be updated in order to fix known egregious bugs. So the reasoning for fixing bugs in a release and not bumping the version is, well, that the only differences are that known bugs have been found and fixed. No changes to API are allowed. So the only changes in output should be that you no longer get incorrect results or errors.
The converse could be asked of you. What is the rationale behind insisting on having an exact setup, where the only difference between setup A and setup B is that setup B has a lower likelihood of doing the 'wrong thing'?
How about seeing whether the new version produces different results than the previous version that was around? If the old version is no longer there, that's kind of difficult.
Or to reproduce someone else's setup exactly to see if the same results can be obtained that they published/reported, and maybe to see whether the newer versions yield better/correct results?
You're sweeping stuff under the rug. Please don't, give people the freedom to play around with old versions, but do keep encouraging the latest versions where bugs have been fixed. Just don't shove it down people's throats without any other option.
The only thing you're going to accomplish there is that people will start organising themselves to build up an archive of older versions themselves, which makes you lose control, and makes it less likely they'll actually pick up the bugfixed versions...
Believe me, I'm not the only one with this frustration.
Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
version 2.3.6
This is expected behavior. Newly released versions replace the previous versions and they go away. If you really need an old version there is always svn.
Then what's the point of having 'releases' like 3.0, if the versions of the packages included in the release get changed (without changing the release version to e.g. 3.0.1, etc.)?
Sorry for your frustration. The issue has come up before (e.g., on the bioc-devel mailing list, on more than one occasion), and we are working toward a better solution. Of course this won't help retrospectively!
One reason why this has been of relatively low priority is because it is not really sufficient (or even necessary) to provide identical tarballs of Bioconductor packages (which are keyed to precise svn revisions, though this information has not been easily obtained). There are, for instance, dependencies on CRAN packages of poorly specified version [current at the time of user installation], as well as challenging system dependencies ranging from compiler to third party libraries. In the end it has historically been the responsibility of the user to ensure a reproducible environment; sorry that you've been caught by this.
The idea of a sub-version of the release has not actually come up before, as far as I remember. I guess this would be incremented more or less daily because with more than 1000 packages it seems that 'critical' bug fixes are pushed somewhere. For many users this would not be helpful, because they would install packages X, Y, and Z during a phase of their analysis on day x, and A and B on some later day y; CRAN dependencies provide further complexity, so in the end it's not really clear that there is a definitive '3.0', and hence not really clear that there's much benefit in pretending there is a 3.0.0, 3.0.1, ... We have talked about creating a snapshot at the end of the release of all Bioc packages and their CRAN dependencies, sort of as close to perfection (far from imperfection?) as Bioc 3.0 got.