On 26/10/2017 12:50 PM, Bruce Hoff 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.
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
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.
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
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.dun...@gmail.com <mailto:murdoch.dun...@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.dun...@gmail.com
<mailto:murdoch.dun...@gmail.com>>
To: Shivaram Venkataraman <shivaram.venkatara...@gmail.com
<mailto:shivaram.venkatara...@gmail.com>>, Ben
Bolker <bbol...@gmail.com <mailto:bbol...@gmail.com>>
Cc: r-package-devel@r-project.org
<mailto: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
<mailto: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
<https://github.com/goldingn/versions>
On Wed, Oct 25, 2017 at 1:05 PM, Ben Bolker
<bbol...@gmail.com <mailto: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.pa
<http://major_version.minor_version.pa>tch_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
<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
______________________________________________
R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<https://stat.ethz.ch/mailman/listinfo/r-package-devel>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org
<mailto:R-package-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
<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
