[Bioc-devel] reverting to older version

Hervé Pagès hp@ge@ @ending from fredhutch@org
Mon Jun 11 20:06:14 CEST 2018


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 using 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: hpages using fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319



More information about the Bioc-devel mailing list