[Bioc-devel] reverting to older version
@b@@t@tgen @ending from gm@il@com
Tue Jun 12 03:33:51 CEST 2018
Thanks, I shall do that. Its OK to keep the master as 1.99.0 ? It should
probably have been 1.19.1 ?
On Monday, June 11, 2018, Hervé Pagès <hpages using fredhutch.org> wrote:
> 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".
> On 06/11/2018 09:27 AM, Samsiddhi Bhattacharjee wrote:
>> 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
>> feature and for that we switched from deterministic p-value calculation to
>> stochastic calculation. We did not notice the issues untill now. We want
>> 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
>> and even after selection these changes will be *many*. Is it ok to
>> a "patch" to the release with a large number of changes? If yes, what
>> should the version number be bumped to?
>> Thanks in advance.
>> [[alternative HTML version deleted]]
>> Bioc-devel using r-project.org mailing list
> Hervé Pagès
> Program in Computational Biolog
> 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
[[alternative HTML version deleted]]
More information about the Bioc-devel