I have been using GNU ELPA and MELPA, but I just switched from MELPA to MELPA-Stable. When I did, I notice that ess-R-data-view is now marked as incompat in the Package Manager. That seems to be because you require ((ctable "20130313.1743") (popup "20130324.1305") (ess "20130225.1754")), which are MELPA-style version numbers.
I don't know if there's a standard way to manage the required version tags across both MELPA and MELPA-Stable, but it would be nice if ess-R-data-view could do that. I'm guessing you are really happy with ctable 0.1.2, popup 0.5.3, and ess 17.11 or less as well as with versions marked with the date codes given in your code. Do tagged releases, which then get picked up by MELPA-Stable, need version tags on all dependencies, while untagged releases, which get picked up by MELPA, need no version tags on dependencies? That is, is the workflow to a) decide to release a "stable" version, b) change all dependency versions to tags, c) tag the package and commit, d) change the dependencies back to dates, and e) commit again to get a new MELPA version? I'm just guessing at this point.
If you could fix that, I think it would enable me and others to use your package with the current "stable" version of ess, ctable, and popup. If I've misunderstood how this should work, please feel free to educate me.
Thank you.
I have been using GNU ELPA and MELPA, but I just switched from MELPA to MELPA-Stable. When I did, I notice that ess-R-data-view is now marked as incompat in the Package Manager. That seems to be because you require ((ctable "20130313.1743") (popup "20130324.1305") (ess "20130225.1754")), which are MELPA-style version numbers.
I don't know if there's a standard way to manage the required version tags across both MELPA and MELPA-Stable, but it would be nice if ess-R-data-view could do that. I'm guessing you are really happy with ctable 0.1.2, popup 0.5.3, and ess 17.11 or less as well as with versions marked with the date codes given in your code. Do tagged releases, which then get picked up by MELPA-Stable, need version tags on all dependencies, while untagged releases, which get picked up by MELPA, need no version tags on dependencies? That is, is the workflow to a) decide to release a "stable" version, b) change all dependency versions to tags, c) tag the package and commit, d) change the dependencies back to dates, and e) commit again to get a new MELPA version? I'm just guessing at this point.
If you could fix that, I think it would enable me and others to use your package with the current "stable" version of ess, ctable, and popup. If I've misunderstood how this should work, please feel free to educate me.
Thank you.