|Re: Changing the plugin ID [message #899003 is a reply to message #898849]
||Mon, 30 July 2012 06:31
| Daniel KrÃ¼gler
Registered: July 2009
On 2012-07-28 04:22, Marian Schedenig wrote:|
> I'm close to finishing a new release of my plugin. One issue is making
> my release preprations complicated though: I have changed the plugin's
> ID since the last version.
> Why? Because my domain has changed. The old one still exists, for now,
> but I've moved everything to the new domain, and I want my package
> structure and ID hierarchy to reflect that.
> I'm fine with people not automatically seeing the new version of the
> plugin as an update for the old one. But I'd like the new version of the
> plugin (with the new ID) to replace the old version (with the old ID)
> when it's installed - otherwise there will be two different versions of
> the same plugin running simultaneously, which is a) pointless and could
> b) cause problems.
> Is there any way to tell the plugin or the associated feature that in
> addition to itself, it also contains a new version of another plugin
> with a custom ID (in my case, the old one)?
A bundle with a new id is a different bundle with no relation to your
previous one. You simply could provide your new bundle plus a new
version of your old bundle. This new version of the old bundle would
contain nothing except that it *reexports* everything from the new bundle.
What I do not understand is how you have thought to solve the packaging
problem: Usually a bundle exports packages that also reflect the bundle
id (at least its domain), e.g. a bundle with id x.y.z publishes packages
and sub-packages of x.y.z. Assuming you do the same, I don't see how you
can help clients with the transition path, because they need to change
their import directives anyway?
HTH & Greetings from Bremen,
|Re: Changing the plugin ID [message #899457 is a reply to message #899003]
||Tue, 31 July 2012 22:23
| Marian Schedenig
Registered: July 2012
The package names aren't an issue, it's only a tool plugin, not an API. To my knowledge, there aren't any custom mods/extensions out there, and even if there are, the new version is more or less a full rewrite of the old one, so compatibility between the two versions is nil anyway.|
Thanks for your suggestion. It makes sense, and I was considering something along those lines. But if I understand correctly, I would have to offer a "dummy feature" (containing the actual feature) with the old ID in addition along with the actual feature - so the update site would basically show the same plugin twice, once with the old ID and once with the new one.
Right now I'm leaning towards simply dropping the old ID and having the new version display an info message if it detects that an old version (with the old ID) is also installed. Not really an elegant solution, but perhaps better than ugly meta dummy feature hacks?
Powered by FUDForum
. Page generated in 0.15890 seconds