Re: [Bioc-devel] reverting to older version

[Hervé Pagès]

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 > 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 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,

         --
         

[Bioc-devel] About CMEA package

[Isar Nassiri]

Dear Martin,


This is the developer of CMEA package.


You have closed the issue because of my delayed response. As I explained in my 
commented message on Nov 12, 2017, my URMC email was terminated, and I did not 
receive your message on time. I read it on the web page of the package and 
revised the package accordingly. Now the package is ready.


Could you please active the issue?  what is the solution?


Related links:
Bioconductor/Contributions
https://github.com/Bioconductor/Contributions/issues/344
Bioconductor Package Builder - Build History
http://bioconductor.org/spb_reports/CMEA_buildreport_20171117051310.html
GitHub repository of the package
https://github.com/isarnassiri/CMEA


Best regards,

Isar

--
Isar Nassiri, PhD.
Researcher
Department of Oncology
MRC Weatherall Institute of Molecular Medicine
University of Oxford
John Radcliffe Hospital
Headington
Oxford OX3 9DS
United Kingdom
Tel: +44 1865 222569
isar.nass...@oncology.ox.ac.uk
--


[[alternative HTML version deleted]]

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

Re: [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  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 
>> 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=
>> > ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAf
>> qt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=
>> fgBGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ=mkxJZC0R8tmJDv
>> J5e5BD4q_sni2JIJB-sCIAkpGut9c=>
>>
>>
>> -- Hervé Pagès
>>
>> Program in Computational Biolog
>> > 

Re: [Bioc-devel] reverting to older version

[Hervé Pagès]

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 > 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.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=fgBGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ=mkxJZC0R8tmJDvJ5e5BD4q_sni2JIJB-sCIAkpGut9c=




-- 
Hervé Pagès


Program in Computational Biolog

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



--
Hervé Pagès

Program in Computational Biology

Re: [Bioc-devel] reverting to older version

[Samsiddhi Bhattacharjee]

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
> 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

Re: [Bioc-devel] reverting to older version

[Hervé Pagès]

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.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=fgBGvYIMbW3NwrKMVPVed43z9LsMyZhyprB7VIWmzRQ=mkxJZC0R8tmJDvJ5e5BD4q_sni2JIJB-sCIAkpGut9c=



--
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

[Bioc-devel] reverting to older version

[Samsiddhi Bhattacharjee]

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