Re: [Bioc-devel] reverting to older version
OK...1.98.0 and 1.99.0 sounds good. Shall do that. Is it necessary to convey the reasons for the change e.g. NEWS file ? That's my last question...I hope ! On Tuesday, June 12, 2018, Hervé Pagès wrote: > Ah ok. Yes 1.99.0 is fine. Then the package will be released as 2.0.0 > in Fall as part of BioC 3.8. > > Not that version numbers have a strong meaning but I was thinking that > maybe you could bump to 1.98.0 in release to sort of indicate the fact > that the package in release is the precursor of what's going to become > 2.0.0 in the next release. If 1.98.0 works as expected, you should > freeze it i.e. only touch it when you absolutely need to fix something > in it. > > Hope this helps, > H. > > On 06/11/2018 06:33 PM, Samsiddhi Bhattacharjee wrote: > >> 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 > hpa...@fredhutch.org>> wrote: >> >> 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 <mailto:Bioc-devel@r-project.org> >> mailing list >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et >> hz.ch_mailman_
Re: [Bioc-devel] reverting to older version
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 wrote: > 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.et >> hz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt >> 84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=fg >> BGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ=mkxJZC0R8tmJDvJ5 >> e5BD4q_sni2JIJB-sCIAkpGut9c= >> >> > -- > Hervé Pagès > > Program in Computational Biolog > <https://maps.google.com/?q=Computational+Biolog=gmail=g>y > 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 > [[alternative HTML version deleted]] ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] reverting to older version
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://stat.ethz.ch/mailman/listinfo/bioc-devel
