R devel - Oct 2011 - RFC: 'igraph' package update and backward compatibility

Dear R developers,

I am seeking advice on some $subject matter.

My package will have an update soon, that is not backward compatible
with the current version. It will likely break much of the existing
code. Many (~50) packages depend on 'igraph' and they, too,  will most
probably break with the new version.

My intended solution is, that I create a snapshot of the current
package, under another name (igraph0), and ask package maintainers to
depend on that version. Then, after a short time, I'll update the
current igraph version.

Do you see any drawbacks of this solution? Is there some existing
practice for situations like this? Suggestions are greatly
appreciated.

Btw. an alternative would be to ask them to depend on the exact
current version of the package. This is an easier solution, but it
won't give people the opportunity to load both versions of the package
at the same time, if they want to run their old code.

Thank You, Best Regards,
Gabor

-- 
Gabor Csardi <csardi.gabor at gmail.com> Dept. Statistics, Harvard
University

On Wed, Oct 19, 2011 at 8:05 PM, Gábor Csárdi <csardi@rmki.kfki.hu> wrote:
> Dear R developers,
>
> I am seeking advice on some $subject matter.
>
> My package will have an update soon, that is not backward compatible
> with the current version. It will likely break much of the existing
> code. Many (~50) packages depend on 'igraph' and they, too,  will
most
> probably break with the new version.
>
Don't forget the indirect dependencies - might be many more.

One approach used by e.g. ggplot and roxygen, is to call the new package
ggplot2 or roxygen2. This would not break old packages.

> My intended solution is, that I create a snapshot of the current
> package, under another name (igraph0), and ask package maintainers to
> depend on that version. Then, after a short time, I'll update the
> current igraph version.
>
I would rather give the new one a a new name by appending the 2

> Do you see any drawbacks of this solution? Is there some existing
> practice for situations like this? Suggestions are greatly
> appreciated.
>
Well - they require immediate action by the package maintainers. Yo could
put a warning in the original iplot package, that the package is not updated
any more and that a switch to iplot 2 is suggested. So no immediate action
by the package maintainers is required.

Cheers,

Rainer

> Btw. an alternative would be to ask them to depend on the exact
> current version of the package. This is an easier solution, but it
> won't give people the opportunity to load both versions of the package
> at the same time, if they want to run their old code.
>
> Thank You, Best Regards,
> Gabor
>
> --
> Gabor Csardi <csardi.gabor@gmail.com> Dept. Statistics, Harvard
University
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

	[[alternative HTML version deleted]]

Thanks for the insight!

It is indeed true that naming the new version 'igraph1' (this is a
better name for the change it introduces), is optimal for the existing
packages.

I was a bit reluctant to do this, because of two reasons. First,
igraph exists as a Python package, and a C library as well, and I was
afraid that it would cause confusion for users to have different names
for the different packages. I can already see the emails with people
asking questions about the difference between Python igraph and R
igraph1 and whether igraph1 is available for Python, etc.

The second reason was that I want users to use the newer version of
the package; I was afraid that most them would probably not notice
that there is a new version under a different name. But this issue is
neatly solved by a warning in the old package, as Rainer suggested.

Hmmmm, it is a hard decision. I think I'll just write an email to the
maintainers of the packages in question and see how many of them
responds. Maybe breaking a couple of unmaintained packages is not a
huge tragedy. But of course I can see the burden for CRAN maintainers
and don't want to exploit them.

Thank you,
Gabor

On Thu, Oct 20, 2011 at 3:27 AM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:
> We've had examples of that approach (e.g. mclust02) and also of
packages
> becoming foo2 (e.g. ggplot2).
>
> The problem is
>
>> ask package maintainers to depend on that version.
>
> In our experience that takes years to achieve! ?I think that any solution
> which requires the maintainers of 50 others to submit new versions is going
> to cause a lot of work for the CRAN crew and not be very comprehensive.
>
> I do prefer the igraph2 route. ?But you also need to be aware that would
> need igraph to be maintained for a long time to come: our experience with
> e.g. ncdf/ncdf4 is that the maintainers simply do not change. ?(In the case
> of ggplot, the author did not even migrate his own dependent packages!)
>
> I think you should assume that a high proportion of packages are not
> actively maintained.
>
> Cc:ed to CRAN, since it is really Kurt's place to advise you what CRAN
would
> like.
>
> Brian Ripley
>
> On Wed, 19 Oct 2011, G?bor Cs?rdi wrote:
>
>> Dear R developers,
>>
>> I am seeking advice on some $subject matter.
>>
>> My package will have an update soon, that is not backward compatible
>> with the current version. It will likely break much of the existing
>> code. Many (~50) packages depend on 'igraph' and they, too,
?will most
>> probably break with the new version.
>>
>> My intended solution is, that I create a snapshot of the current
>> package, under another name (igraph0), and ask package maintainers to
>> depend on that version. Then, after a short time, I'll update the
>> current igraph version.
>>
>> Do you see any drawbacks of this solution? Is there some existing
>> practice for situations like this? Suggestions are greatly
>> appreciated.
>>
>> Btw. an alternative would be to ask them to depend on the exact
>> current version of the package. This is an easier solution, but it
>> won't give people the opportunity to load both versions of the
package
>> at the same time, if they want to run their old code.
>>
>> Thank You, Best Regards,
>> Gabor
>>
>> --
>> Gabor Csardi <csardi.gabor at gmail.com> Dept. Statistics,
Harvard University
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, ? ? ? ? ? ? ? ? ?ripley at stats.ox.ac.uk
> Professor of Applied Statistics, ?http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, ? ? ? ? ? ? Tel: ?+44 1865 272861 (self)
> 1 South Parks Road, ? ? ? ? ? ? ? ? ? ? +44 1865 272866 (PA)
> Oxford OX1 3TG, UK ? ? ? ? ? ? ? ?Fax: ?+44 1865 272595


-- 
Gabor Csardi <csardi at rmki.kfki.hu>? ?? MTA KFKI RMKI

> My package will have an update soon, that is not backward compatible
> with the current version. It will likely break much of the existing
> code. Many (~50) packages depend on 'igraph' and they, too, ?will
most
> probably break with the new version.
>
> My intended solution is, that I create a snapshot of the current
> package, under another name (igraph0), and ask package maintainers to
> depend on that version. Then, after a short time, I'll update the
> current igraph version.
The optimal solution would be if R packages could depend on a specific
version of a package, and a user could have multiple packages
installed, and different versions loaded simultaneously so that
different packages could depend on different versions.  This is what
(e.g.) ruby gems do. Unfortunately this is a hard problem to solve -
namespaces go some way to help, but I think there are still
outstanding S3 and S4 issues.

My work around of renaming packages after API breaking changes is
definitely a sub-optimal fix.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/