Skip to content

[R-pkg-devel] Semantic versioning and maintenance releases

5 messages · Duncan Murdoch, Bruce Hoff, Shivaram Venkataraman

Original
Bruce Hoff
# 
Hi:
Respectfully, I don't see why this would be a problem for the author of
'mypackage'.  The author of 'mypackage' is simply one of Shivaram's users
(a consumer of 'yourpackage').  He/she decides whether to depend on v 1.6.3
*or* v 1.7.0 then builds, tests and publishes the appropriate revision of
'mypackage'.  The author of 'mypackage' is free to move up to 1.7.0 when
he/she sees fit, e.g., based on what additional functionality is included
in 1.7.0.

Also, it doesn't seem too bad for CRAN to only allow monotonic increases in
version numbers.  I would hope that Shivaram's series of revisions are
backwards compatible and that the 'patch' included in 1.6.3 is also
included in 1.7.0.  So he should be able to publish 1.7.0 to CRAN and ask
his users to update to that version to get the patch.   There should be no
downside of having the other changes to 'yourpackage'.  If, on the other
hand, 'yourpackage' has changed from 1.6 to 1.7 so much that it computes
different results, then perhaps it should be published under a different
package name ('yourpackage-2').  In that case CRAN should allow both
packages to exist side-by-side in the repository.

Cheers,

Bruce


Date: Wed, 25 Oct 2017 16:45:22 -0400
From: Duncan Murdoch <murdoch.duncan at gmail.com>
To: Shivaram Venkataraman <shivaram.venkataraman at gmail.com>, Ben
        Bolker <bbolker at gmail.com>
Cc: r-package-devel at r-project.org
Subject: Re: [R-pkg-devel] Semantic versioning and maintenance
        releases
Message-ID: <d090ebf0-8c42-99b5-58ca-355ebb25b832 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 25/10/2017 4:28 PM, Shivaram Venkataraman wrote:
I think this would make life harder for CRAN and for other developers,
so it's unlikely to happen.

For example, suppose both yourpackage 1.6.3 and 1.7.0 are active on
CRAN, and mypackage declares that it depends on yourpackage.  Then if I
upload an update to mypackage, which version of yourpackage does CRAN
install when testing my update?  It would have to test both.

And if mypackage depended on herpackage and hispackage that also had
multiple active versions on CRAN, things would become unwieldy very quickly.

Duncan Murdoch
than

  
  


  


    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 26/10/2017 10:36 AM, Bruce Hoff wrote:

            

      
      
      
    

        
You could do that, but it would be very unusual (and fragile) to have 
your package depend on a particular version of another package.  The 
more common thing is to say "Depends:  yourpackage" (or "Imports:", 
etc.), with no version dependency.  Users installing mypackage would 
need to have some version of yourpackage installed, but R would be happy 
with either one.

When there's only one active version of yourpackage, CRAN enforces 
quality by requiring that any update to yourpackage doesn't break 
mypackage (and the other reverse dependencies), and that any update to 
mypackage works with the latest yourpackage.  That's already a lot of 
work.  When I was testing for CRAN, a few packages required 10 or 20 
hours of testing when they submitted an update.

The problem arises if both versions of yourpackage are on CRAN with 
equal status.  Then CRAN shouldn't accept mypackage unless it works fine 
with both, but that's twice as much testing.  And in the extended 
version with n packages having m active versions, it's m^n times as much 
testing.

Duncan Murdoch

  The author of 'mypackage' is free to move up to 1.7.0 when

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Bruce Hoff
    

    

      
      #
    

  


  

      
I respectfully disagree that it's "fragile" to depend on a particular
version of a package.  On the contrary I think it's the foundation of
making software stable.  Having said this, reading the rest of your
description of how CRAN works is enlightening and emphasizes an underlying
philosophy about backwards compatibility.  As you say:

            

      
      
      
    

        
So, returning to Shivaram's original question, the answer would be:  You
need to write v 1.7.0 so that it is acceptable to anyone who currently uses
1.6.2. The patch (1.6.3) would be included in 1.7.0 along with other
changes you've made in the course of developing the package.  Those other
changes should not negatively affect anyone currently depending on 1.6.2.
You then publish 1.7.0 to CRAN, for all (both those who want the 1.6.3
patch and those who want the 1.7.0 new features) to adopt.  If you cannot
make 1.7.0 acceptable to current 1.6.2 users, then it has to be published
as a different package ("yourpackage-2").
Thank you,
Bruce


On Thu, Oct 26, 2017 at 7:53 AM, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Shivaram Venkataraman
    

    

      
      #
    

  


  

      
FWIW the patches in 1.6.3 are always a part of 1.7.0 -- its just that 1.7.0
has a lot of other new stuff in it as well and enterprises are sometimes
more likely to upgrade to a patch release rather than the next minor
version.

Overall I think my understanding from this thread is that one should see
CRAN as the package dependency manager which has the latest stable version
of a package and not necessarily all the available versions for a package.
For hosting prior versions including patch releases its typically better to
use a separate repository (e.g., github) and give users instructions on how
to use this. Of course in this case the user is taking responsibility of
figuring out if this version is compatible with all their other packages.

Thanks
Shivaram

        
On Thu, Oct 26, 2017 at 9:50 AM, Bruce Hoff <bruce.hoff at sagebase.org> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 26/10/2017 12:50 PM, Bruce Hoff wrote:

            

      
      
      
    

        
In general that might be true, but for R it's not.  If mypackage 
requires version 1.7.0 of yourpackage, and you release 1.7.1, suddenly 
lots of people will have trouble installing mine, because although CRAN 
will keep 1.7.0 around indefinitely, it won't keep binary builds of it 
around.  Lots of Windows and Mac users depend on CRAN to do the building 
for them.

 ? Having said this, reading the rest of your

            

      
      
      
    

        
I oversimplified that a bit.  CRAN doesn't absolutely require backwards 
compatibility, they just discourage incompatibility by requiring you to 
help your reverse dependencies cope with changes.  If your update breaks 
a revdep, you need to explain what you did to help the revdep author 
cope with it, and it needs to be enough that CRAN agrees that package 
author is being negligent by not adapting.  Or something like that.

Duncan Murdoch

The patch (1.6.3) would be included in 1.7.0 along with