I can only encourage you to keep track of the most significant changes
in your package in its NEWS file, especially if its history is a little
bit complicated as it seems to be the case here. Briefly explaining the
motivations behind those changes is a good idea.

Cheers,
H.


On 06/11/2018 08:47 PM, Samsiddhi Bhattacharjee wrote:
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 <mailto: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> <mailto: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>
        <mailto:Bioc-devel@r-project.org <mailto:Bioc-devel@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=
        
<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=>
<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=
        
<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 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=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yK9EcNtuXJxVARcKqhhDNsaafTbhs3BL6XY0N6Jg9Do&s=AHsUDoAQB3QsfUp0YXfRbO6LCtWkCM0BLKJzCMlqYsE&e=
        
<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3DComputational-2BBiolog-26entry-3Dgmail-26source-3Dg&d=DwMFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=yK9EcNtuXJxVARcKqhhDNsaafTbhs3BL6XY0N6Jg9Do&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>
        <mailto: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 <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

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to