| kimcinoo |
Certain unnamed parties have grown to depend on internal API details of
ecore_wl2, despite it being labelled as beta api.
In an effort to promote peace and harmony we're surrendering the ecore_wl2
namespace to anyone that didn't notice it was beta api, and renaming
the library to something more obviously not stable.
This allows people dependent on ecore_wl2 unstable bits to create them
in a thin shim layer around the notstable library.
ref T7171
| Lint OK |
| No Unit Test Coverage |
| Buildable 9365 |
It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/
I'd like to see a travis build success but otherwise this seems like a smart way to discourage external use.
I'm unsure that this is really the best approach ... what happens in the future if/when this library Does get to Stable ?? Are we then going to rename the library again ??
Just out of curiosity, How do you know that ? Did you get a new magic crystal ball for Christmas that you are not sharing ?? :)
Jokes aside, that's not a very escalable name, what are we going to do with the next library we need to mark as not stable?
How about using notstable as a prefix instead of the whole lib name? As in notstable_ecore_wl2.
Suggested alternative prefixes: experimental, unstable, volatile, flammable, poisonous, 유해한
I agree with @segfaultxavi in that this needs a better name. I am not against the rename of the library, just that I think a more mutable name would be preferred (in the event that we ever decide to mark this as stable). One question ... does it Have to be a prefix ? Why not something like ecore_wl2_unstable ?
Well, anything with ecore_wl2 in it should be considered right out, because the whole point of this is to surrender that namespace, and sort of continuing to use it with a prefix will be confusing...
I'm quite certain that notstable2 or alsonotstable or notstablethesecond would be available if there happened to be a second library with this same issue.
I don't much see the point in adding more prefixing/suffixing to the namespace. The name ecore_wl2 is pretty meaningless as it isn't truly a component of ecore, and wl2 is an abbreviation which means little to most people anyway. Furthermore, we do indeed want to avoid anything resembling the existing namespace/api so that people don't use it.
I pretty much agree with Xavi. And i am really wondering why people start to use something obviously flagged as beta, and then complain about something which is updated within a beta'ed scope. However, i don't really see here a reason for putting that much work of updating this, and enlightenment, on us, just because someone else is not respecting beta API. Therefore i would love to keep ecore_wl2 beeing ecore_wl2.
The solution i would prefer here is:
After that ecore_wl2 aka *high-version*, and ecore_wl2 aka *normal efl version* can be installed in parallel, and both can be linked in the same application, no symbol clashing, and no additional work for us. In the same move i would actaully propose something like another header define in the Ecore_Wl2.h file which is set to the last commit touching ecore_wl2 in efl ... :)
This does not seem to be a viable solution. The point of renaming is that third parties will continue to use the same API and symbols which exist in ecore-wl2 now and we do not want to cause conflict when we eventually change these symbols again. Providing a separate repository with symbols that do not match the existing symbols is completely useless to everyone.
The one drawback I see to this approach is that if a request is made, or a new feature implemented, or some major bug gets fixed...now it needs to be updated in 2 places...