[Bioc-devel] reverting to older version

[Samsiddhi Bhattacharjee]

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

	[[alternative HTML version deleted]]