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

Shivaram Venkataraman shivaram.venkataraman at gmail.com
Thu Oct 26 19:09:41 CEST 2017 

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:

> 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:
> > CRAN [requires] that any update to yourpackage doesn't break mypackage
> 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:
>
> > On 26/10/2017 10:36 AM, Bruce Hoff wrote:
> >
> >> Hi:
> >>
> >> 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.
> >>>
> >>
> >> 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'.
> >>
> >
> > 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
> >
> >> 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:
> >>
> >>> 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
> >>>
> >>>
> >>         [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> 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
>

	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list