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 <hpa...@fredhutch.org> 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 <mailto: >> 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_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt >> 84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=fg >> BGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ&s=mkxJZC0R8tmJDvJ5 >> e5BD4q_sni2JIJB-sCIAkpGut9c&e= >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__stat. >> ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwICAg&c=eRAMFD45gAf >> qt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m= >> fgBGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ&s=mkxJZC0R8tmJDv >> J5e5BD4q_sni2JIJB-sCIAkpGut9c&e=> >> >> >> -- Hervé Pagès >> >> Program in Computational Biolog >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps. >> google.com_-3Fq-3DComputational-2BBiolog-26entry-3Dgmail- >> 26source-3Dg&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvim >> eWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yK9EcNtuXJxVARcKqhhDNsaaf >> Tbhs3BL6XY0N6Jg9Do&s=AHsUDoAQB3QsfUp0YXfRbO6LCtWkCM0BLKJzCMlqYsE&e=>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 <mailto:hpa...@fredhutch.org> >> Phone: (206) 667-5791 >> Fax: (206) 667-1319 >> >> > -- > 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 > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
