Page MenuHomePhabricator

wayland: Rename ecore_wl2 to notstable
Needs ReviewPublic

Authored by ManMower on Feb 5 2019, 8:20 AM.

Details

Reviewers
kimcinoo
Maniphest Tasks
T7171: Rename ecore_wl2
Summary

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

Diff Detail

Repository
rEFL core/efl
Branch
ecore_wl2_rename
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 9364
ManMower created this revision.Feb 5 2019, 8:20 AM

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/

ManMower requested review of this revision.Feb 5 2019, 8:20 AM
ManMower updated this revision to Diff 19200.Feb 5 2019, 8:22 AM
ManMower retitled this revision from wayland: Rename ecore_wl to notstable to wayland: Rename ecore_wl2 to notstable.

fix typo in commit log

zmike added a subscriber: zmike.Feb 5 2019, 8:26 AM

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 ??

zmike added a comment.Feb 5 2019, 8:33 AM

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 ??

This library will never be stable. Ever.

Just out of curiosity, How do you know that ? Did you get a new magic crystal ball for Christmas that you are not sharing ?? :)

zmike added a comment.Feb 5 2019, 8:44 AM

Got it from corporate as my end of year gift. Sale is still ongoing!

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...

zmike added a comment.Feb 5 2019, 9:29 AM

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'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.

bu5hm4n added a subscriber: bu5hm4n.Feb 5 2019, 9:36 AM

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:

  • Move the ecore_wl2 this party uses to a external repository, copy over the meson files,
  • Change every API in that repository, from <API> to _<API> and define in a header file #define <API> _<API>
  • Change the version to 1337.7331.
  • Release this repository and make clear that there is 0 support for it, you are on your own if you use that.

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 ... :)

zmike added a comment.Feb 5 2019, 9:41 AM

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:

  • Move the ecore_wl2 this party uses to a external repository, copy over the meson files,
  • Change every API in that repository, from <API> to _<API> and define in a header file #define <API> _<API>
  • Change the version to 1337.7331.
  • Release this repository and make clear that there is 0 support for it, you are on your own if you use that.

    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.

In D7881#140069, @zmike wrote:

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'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:

  • Move the ecore_wl2 this party uses to a external repository, copy over the meson files,
  • Change every API in that repository, from <API> to _<API> and define in a header file #define <API> _<API>
  • Change the version to 1337.7331.
  • Release this repository and make clear that there is 0 support for it, you are on your own if you use that.

    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 ... :)

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...