[Bioc-devel] reverting to older version
Hervé Pagès
hp@ge@ @ending from fredhutch@org
Tue Jun 12 06:27:40 CEST 2018
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 <hpages using fredhutch.org
> <mailto: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> <mailto: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>
> <mailto: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.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: hpages using fredhutch.org <mailto:hpages using fredhutch.org>
> <mailto: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 <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
More information about the Bioc-devel
mailing list