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.dun...@gmail.com>
To: Shivaram Venkataraman <shivaram.venkatara...@gmail.com>, Ben
Bolker <bbol...@gmail.com>
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Semantic versioning and maintenance
releases
Message-ID: <d090ebf0-8c42-99b5-58ca-355ebb25b...@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 <bbol...@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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
