Skip to content

[Bioc-devel] Resetting to previous commits

7 messages · Erik Fasterius, Kasper Daniel Hansen, Mike Smith +1 more

#
I made some changes to my seqCAT package the last few days in order to prepare for version 1.0.0 of tidyr, which was apparently harder than I initially thought. I was also a bit too quick with pushing to Bioconductor (both the release and devel branches), and now I?ve got several updates and versions that don?t work - very stupid of me, I know. I do seem to have a working version now, though, and I finally learnt my lesson and have NOT pushed this to Bioconductor yet. Now I want to reset to the previously working versions of my package (1.6.0 for release and 1.7.2 for devel)

I did try to make (temporary) hard resets and force push these to Bioconductor (as per the ?reset to a previous commit? in the ?abandon changes? developer section), but these did not work: all I got was errors say I cannot move from a higher version (e.g. 1.6.2) back to a lower one (1.6.0). Is there a way to bypass this? If not, I assume I?ll just have to make a new version for each branch (1.6.3 and 1.7.5, as it were) and push those, leaving several non-functional versions at Bioconductor? If at all possible I?d like to avoid this.

Again, I realise these problems are because of errors on my part, and would like to know if I can solve them somehow or if I?ll just have to live with them.
#
You cannot revert. By pushing those updates, you released a version into
the wild. It is true that as long as it doesn't build on the build servers,
it would have been hard to obtain for anyone, but it is still possible
through git. You need to update the version.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <erik.fasterius at outlook.com>
wrote:

  
    
#
Also, it is not clear to me if this qualifies for a update to the release
branch. Updates to release should be restricted to critical bug fixes
(although if tidyr updates will break your package, that sounds like a
critical bug fix to me)

Note to others: this (again) emphasizes that we may need to "copy" a
snapshot of CRAN into release.

Best,
Kasper

On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <
kasperdanielhansen at gmail.com> wrote:

            

  
    
#
Thank you for the prompt response! I will just add more versions on top of what I have already added. Would it be correct to assume that Bioconductor will try to build the most recent version available, even though it failed builds for previous versions?

Regarding the change, it was indeed a breaking change, and I thus believed that it would have been counted as a bug-fix for the release branch.

All the best,
Erik
On 14 Aug 2019, at 17:15, Kasper Daniel Hansen <kasperdanielhansen at gmail.com<mailto:kasperdanielhansen at gmail.com>> wrote:
Also, it is not clear to me if this qualifies for a update to the release branch. Updates to release should be restricted to critical bug fixes (although if tidyr updates will break your package, that sounds like a critical bug fix to me)

Note to others: this (again) emphasizes that we may need to "copy" a snapshot of CRAN into release.

Best,
Kasper
On Wed, Aug 14, 2019 at 11:13 AM Kasper Daniel Hansen <kasperdanielhansen at gmail.com<mailto:kasperdanielhansen at gmail.com>> wrote:
You cannot revert. By pushing those updates, you released a version into the wild. It is true that as long as it doesn't build on the build servers, it would have been hard to obtain for anyone, but it is still possible through git. You need to update the version.

Best,
Kasper
On Wed, Aug 14, 2019 at 11:05 AM Erik Fasterius <erik.fasterius at outlook.com<mailto:erik.fasterius at outlook.com>> wrote:
I made some changes to my seqCAT package the last few days in order to prepare for version 1.0.0 of tidyr, which was apparently harder than I initially thought. I was also a bit too quick with pushing to Bioconductor (both the release and devel branches), and now I?ve got several updates and versions that don?t work - very stupid of me, I know. I do seem to have a working version now, though, and I finally learnt my lesson and have NOT pushed this to Bioconductor yet. Now I want to reset to the previously working versions of my package (1.6.0 for release and 1.7.2 for devel)

I did try to make (temporary) hard resets and force push these to Bioconductor (as per the ?reset to a previous commit? in the ?abandon changes? developer section), but these did not work: all I got was errors say I cannot move from a higher version (e.g. 1.6.2) back to a lower one (1.6.0). Is there a way to bypass this? If not, I assume I?ll just have to make a new version for each branch (1.6.3 and 1.7.5, as it were) and push those, leaving several non-functional versions at Bioconductor? If at all possible I?d like to avoid this.

Again, I realise these problems are because of errors on my part, and would like to know if I can solve them somehow or if I?ll just have to live with them.
_______________________________________________
Bioc-devel at r-project.org<mailto:Bioc-devel at r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
Best,
Kasper


--
Best,
Kasper
#
Yes, the Bioconductor build system will only try to build the most recent
version in the git repository.  If it never managed to successfully build a
particular version then that version should not appear anywhere on the Bioc
site.  For example biomaRt is now on release 2.40.3, but version 2.40.2
never passed all the checks, and so is absent from the archive at
https://bioconductor.org/packages/3.9/bioc/src/contrib/Archive/biomaRt/  In
theory someone could get hold of it via git, anyone doing so it probably
experienced enough to look after themselves.

Best,
Mike

On Wed, 14 Aug 2019 at 18:12, Erik Fasterius <erik.fasterius at outlook.com>
wrote:

  
  
#
Yes, it will build the most recent version

If the previous build failed it will even build the most recent code, even
if the code is not bumped. The exception is the following
  you update package A to version X, build succeeds
  you commit code to package A, but does not bump the version
This will not trigger.a rebuild and your latest commits will not be
reflected in the tarballs available to the community. This is why you -- in
general -- need to bump versions when you commit code.

Pro-tip: In general, you will be well served not to get too attached to
version numbers. Bump it frequently even without new functionality or bug
fixes and just live with the frequent bumping.
On Wed, Aug 14, 2019 at 12:43 PM Mike Smith <grimbough at gmail.com> wrote:

            

  
    
#
On 8/14/19 10:19, Kasper Daniel Hansen wrote:
...
+1 for Best Advice Of The Week.