|
|
+1 to that. I'd increase severity to major.
Considering we already made plugin author's lifes difficult with the switch from 1.2 to 1.3 (switch to div-based layouts, removal of alternate rows, etc), we should try to ease the transition from 1.3 to 2.0 and if possible maintain compatibility.
I suggest increasing severity to major. |
|
|
If you cannot upgrade the plugin while being part of MantisBT core team, maybe you should stick with v1.3 (or fork for your own special version)
Rafik, no, i'm perfectly capable of upgrading my plugins.
The solution purposed here is beyond terrible
No, let me explain, and take the chance to understand my reasoning:
I understand that redesigning the UI has introduced breaking changes. Such a change is having the form layout as tables, instead of divs.
Mantis 1.3 has just been released as stable, so plugin developers may still be porting their plugins to 1.3 styles (eg, table forms to divs), and we will force them to port again to a new ui (eg, div forms to tables). Even if justified as part of the new UI project, that is a burden to developers that may want to keep up to date, or even test their plugins against the 2-beta versions.
As @dregad has said: let's try to ease their lifes as much as possible.
maybe you should stick with v1.3 (or fork for your own special version)
That's not the motivation of the project, as i was informed when i joined the team.
One of our priorities is to "add value".
Think that there may exist some plugins that may be stalled without active development, which can work fine in v2, but actually they wont because its manage page fails to load. We risk that some users may not upgrade to v2 becasue a plugin he depends on for some reason is not going to be ported. So losing postential users is not adding value.
Saying that a developer should stick to an old version, or risking the chance that a developer may not port his plugins to new version (because of a increased refactor ovehead may not worth for him), is not value either.
Why don't you upgrade the plugins to modern-ui instead?
Yes i can upgrade, when i have the time to do so, and the motivation. I'm thinking as a external plugin developer here:
If v2 is not stable yet, why should i do the work?
Even if i decide to, if the first thing i see is a fatal error, i'm going to feel discouraged. Probably i will delay that task until v2 is officially released and a growing user base is actually on it.
This means that v2 will be launched with a little plugin base, delaying potential user adoption (see previous point of adding value)
Is the code not available on GitHub?
no, my plugin is still in development
Upgrading is not that hard.
Not theoretcally.
But, as an example, in said plugin i have around 20 manage pages. Rewriting all the forms from div to tables, with the new styles is going to take a while.
Additionally, the new ui classes and structure is not very intuitive, i could not do it right away and need some time figuring what the styles mean and how to use them properly.
Now,back to the original point.
I'd rather have a plugin that works as a sepcial case of a degraded UI, than one that fails fatally.
Take in mind, plugins are one of the greatest values of this application, and the reason why many users have chosen it over other solutions.
Myself as an example, the plugin capabilities made me stick with mantis, and eventually, actively contribute to it.
I thought the reason we are labeling modern UI as v2.0 is to make breaking changes (otherwise we should call it v1.4)
This is where i refer also to PR 927
I'm in favour of introducin breaking changes that are unavoidable. But that is not a free ticket to break everything.
In the case of that PR:
- with v2, print_button() was renamed to print_form_button(), adding only css tweaks.
- with v2, a new incompatible print_button() was created.
if it is "desirable" to break old UI related api calls, then why not break also other functions, like i mentioned: html_button().
Otherwise, that is an unnecesary change, and PR 927 just renames the new function to not collision the already existant one (whose actual functionality has not changed)
I'd like other developers to express his opinion here. Even some plugin developers are welcomed to chime in. |
|
|
Maybe the injection of functions and css that is done in PR 926, can be done from a separate plugin:
- css provided by standard plugin functionality
- functions included in global scope as part of the source included
I'm not sure, but i'm optimistic that it could be done...
This way it's separated from core, and can be enabled by the user. That may be enabled by default in beta releases, and set it disabled once stable is reached?
Are you more confortable with that approach @vboctor, @syncguru ? |
|
|
@cproensa your point is valid if, and only if, this was a common request from plugin authors and we are bombarded by requests to support classic plugins in Modern UI (... still sounds weird). I don't see that. We have a single data point (i.e. you). There is simple solution for such scenario that is offered by default for every open source project. That is: Fork for your own special case and maintain your fork.
One of our priorities is to "add value".
True ... not sure how enabling a private plugin would add value to anyone. Again, we are not under any pressure from plugin authors to do this. At least, not yet.
Think that there may exist some plugins that may be stalled ............ losing potential users ......
Come on @cproensa, that's called speculation. We have enough channels to get complains & feedback. Let's not try to fix a problem that we have no evidence that it even exists.
In my opinion, i agree that if it can be bundled in a plugin, it's better than in core.
I am fine with that. I only care about core code base. You are free to do whatever you want as plugin or fork.
|
|
|
your point is valid if, and only if, this was a common request from plugin authors and we are bombarded by requests to support classic plugins in Modern UI (... still sounds weird)
you dont have understoodd my point. I am NOT proposing supporting classic ui as a matter of fact.
What i am trying to do is to provide a minimal fallback so when a plugin developer, or a migrating user comes to test the new mantis version, dont get to find that they get a fatal error screen.
we are bombarded by requests
We don't have to wait to be bombarded by requests by users to do something if we think it's a good thing.
In this case, we don't want to wait to piss some developers so that they can complain before doing a mitigation measure and help with the transition.
True ... not sure how enabling a private plugin would add value to anyone
A version upgrade with your plugins working fine, is better value than have them fail with errors.
Not having to force the users to upgrade their plugins if not strictly needed, is added value.
Having developers to be able to test plugins on our beta versions, without having to do any rewrite beforehand, is added value.
Happy users instead of pissed users, is added value.
Let's not try to fix a problem that we have no evidence that it even exists
You have evidence as far as i have reported the errors.
As a plugin developer myself, i have an opinion of what would be expectable from a version change, what not, and what seems like an unncesary change.
As a team developer i also have an opinion of what is reasonable to do in code base and what not.
that's called speculation
No, i'm trying to think ahead what is benefitial to the project.
I only care about core code base.
Well, I care about code base too. And also I care about the plugin system.
Do you care about the plugin capabilities, or have you done heavy work plugins with it?
If not, maybe you should pay more attention to those who have done so.
There is simple solution for such scenario that is offered by default for every open source project. That is: Fork for your own special case and maintain your fork.
No, we should listen for request and ways to improve, if they are valid and feasible. A fork is not provided as a solution, it's a right by being OS.
You are free to do whatever you want as plugin or fork.
I wouldn't be contributing to this project if that was my default approach for every issue that happened.
I want to discuss the issue in a constructive way
As you see, i have come to the position that this can be done with a plugin, instead of modifying core. I have thinked of it by ignoring your stubbornness on negating the point, and still trying to think by your arguments. This could have been easier if discussion had been more constructive from the start.
At the relevant point:
- This can be done entirely from a plugin
- I still propose the plugin is included in mantis and enabled by default in beta versions.
|
