Hi,
Having a package that is known to be broken in release is not
really an option.
How about replacing all the files in the RELEASE_3_7 branch
with what's in the master branch. For the version, just bump
z (in x.y.z) to its next version. Don't touch x or y. So the
version would become 1.18.1 in release. Then commit (it's going
to be a single commit) with a commit message that says something
like "Resync with master branch".
Cheers,
H.
On 06/11/2018 09:27 AM, Samsiddhi Bhattacharjee wrote:
Hi,
I am maintainer of package ASSET. We have recently discovered some issues
(most importantly computational speed issues) with recent versions of our
package and wanted to revert the code to an older version ASSET v 1.8.0
present in Bioconductor release 3.2, before proceeding to make further
enhancements to the package.
In release 3.3 , there were major changes to the package, it is like a
branch that we now realize that we need to abandon. We had introduced a new
feature and for that we switched from deterministic p-value calculation to
stochastic calculation. We did not notice the issues untill now. We want to
switch back to the deterministic one, which was present last in 3.2.
As suggested by Nitesh, I have made the changes in devel branch (basically
by copying the code as it was in release 3.2, and only updating the
DESCRIPTION file make the version 1.99.0 as this will be a major change
(although we are taking a few steps back, we will probably add some steps
forward before release 3.8).
I wanted to put a .onAttach() message in the current version to make the
user aware of the issues and possibly mentioning the next release and/or
pointing to the older release. However, as Herve
has pointed out, people may mix up devel and release versions causing
problems. Hence Herve had suggested:
"It will be much better if you actually fix the release version of your
package. This should just be a matter of porting the fixes you do in devel
with 'git cherry-pick'."
Reason I am hesitating is that the changes (diff of 3.7 and 3.2) are quite
a lot and doing selective changes as suggested will introduce further bugs,
and even after selection these changes will be *many*. Is it ok to backport
a "patch" to the release with a large number of changes? If yes, what
should the version number be bumped to?
Thanks in advance.
Regards,
--
Samsiddhi
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=fgBGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ&s=mkxJZC0R8tmJDvJ5e5BD4q_sni2JIJB-sCIAkpGut9c&e=
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
