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

Duncan Murdoch murdoch.duncan at gmail.com
Wed Oct 25 22:45:22 CEST 2017


On 25/10/2017 4:28 PM, Shivaram Venkataraman wrote:
> Thanks for all the replies. I can see that the monotonic ordering is
> in-built to support the latest / best version model that CRAN has. That
> said it would be great if the policy could be relaxed to allow uploading
> older versions which don't necessarily become the "best" version.
> Then we could ask users to use versions[1] and run something like do
> `install.versions('mypackage', '1.6.3')` if they really want to be in the
> 1.6.x series.

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


> 
> Thanks
> Shivaram
> 
> [1] https://github.com/goldingn/versions
> 
> On Wed, Oct 25, 2017 at 1:05 PM, Ben Bolker <bbolker at gmail.com> wrote:
> 
>>
>>
>> On 17-10-25 03:47 PM, Duncan Murdoch wrote:
>>> On 25/10/2017 2:23 PM, Shivaram Venkataraman wrote:
>>>> Hello
>>>>
>>>> We have an R package that uses semantic versioning -- i.e. version
>>>> numbers
>>>> are of the form major_version.minor_version.patch_version
>>>>
>>>> One of the ways we use the patch_versions is to make maintenance
>> releases
>>>> or security fixes that users can apply without worrying about any
>>>> functionality changes. For example if our users were on 1.6.2 it is
>> often
>>>> easier for them to upgrade to 1.6.3 which has a security fix rather than
>>>> 1.7.0
>>>>
>>>> On the other hand our development continues towards the next minor
>>>> version
>>>> and we sometimes have cases where say 1.6.3 is released after 1.7.0.
>>>>
>>>> While running `R CMD check --as-cran` for version 1.6.3 we find that
>> this
>>>> leads to a warning which looks like 'Insufficient package version
>>>> (submitted:
>>>> 1.6.3, existing: 1.7.0)'.
>>>>
>>>> Our question is whether it is okay to upload these maintenance
>>>> releases to
>>>> CRAN and if there is some way we can mark that the version numbers
>> follow
>>>> semantic versioning.
>>>
>>> CRAN won't accept 1.6.3 after 1.7.0 has been published there.  It
>>> requires version numbers to be increasing.  There's no provision for the
>>> scheme you're following.
>>>
>>> Even if there were, it's not easy for a user to ask to install any
>>> version but the latest one.  They'd need to work out the URL and
>>> download the tarball and build it from source.  install.packages() has
>>> no provision for handling this automatically.
>>
>>    If an older version *were* on CRAN (I understand why this isn't
>> feasible), devtools::install_version() would take care of some of the
>> fussy bits (although it still requires having the build tools installed).
>>
>>    You can use the 'ref' argument in devtools::install_github to point
>> your users to a tag/release number ...
>>
>>> I'd suggest that you put the patch releases for older versions on Github
>>> or some other repository, and explain how users can install directly
>>> from there.
>>>
>>> Duncan Murdoch
>>>
>>> ______________________________________________
>>> R-package-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ______________________________________________
>> R-package-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>



More information about the R-package-devel mailing list