[João Valverde <j@xxxxxx>]

Regarding questions I would like to know if is Wireshark is developed, 
including each of the three existing libraries, for other projects to 
add as dependencies to their software stack. It is possible I need to 
adjust my understanding and expectations accordingly, and I will do so.

External plugins developed independently are not really relevant to this 
discussion. Plugins are not independent projects in a technical sense, 
they depend on Wireshark as a whole and not only any particular 
Wireshark library.

If we wanted to release system shared libraries, in the style of libpcap 
like Balint intends, I think it would be important to split them out of 
the main repo, with their own build system, lifecycle, clearly defined 
purpose, versioning, API/ABI policy, release cadence, etc. It would also 
be important to restructure the source tree, at a minimum to add an 
include folder for each library.

This would be how to develop, maintain and release a library properly, 
in my opinion. That's why I said in the Gitlab issue a shared library 
should be implemented bottom up and not the other way around, like it 
was done here.

On 20/01/22 20:34, Gerald Combs wrote:
> If I understand the discussion in issue 17822 and here, we're looking 
> at the following questions (feel free to correct me where needed):
>
> Q: Should we commit to a stable ABI between minor releases?
>
> I think everyone agrees that we should, or at least that it's a 
> worthwhile goal.
>
> Q: Should *wsutil* be part of that stable ABI?
>
> Debian, Ubuntu and (according to rpmfind.net) OpenSuSE and Mageia 
> treat it as such. It would be helpful to know what non-Wireshark 
> packages depend on wsutil in those distributions and elsewhere.
>
> Q: What's the best way to ensure stability?
>
> That's a tricky one. We did so in the past using 
> abi-compliance-checker, but that was removed in 6e5ba74b. I think it 
> would be worthwhile to try adding it back in a more simplified form 
> for release branches, but I'm not sure when I would have time to work 
> on that.
>
> On 1/20/22 7:29 AM, Roland Knall wrote:
> > For clarification: " but the change should most certainly happen with 
> > a version beyond 3.6" means, that the break should be reverted for 
> > 3.6.x, but it should be put in place for -dev to be in the next major 
> > release
> >
> > cheers
> >
> > Am Do., 20. Jan. 2022 um 16:28 Uhr schrieb Roland Knall 
> > <rknall@xxxxxxxxx <mailto:rknall@xxxxxxxxx>>:
> >
> >     I think it is reasonable to assume that libraries provided with 
> > the project are being used by external programs. I know one utility 
> > which is being used in a rather closed-off community (but 
> > nonetheless widely adopted by around 200-300 people), which got 
> > broken by this. Their solution is to stay on 3.4 until either 3.6 is 
> > fixed or the utility (which probably will be done in this case).
> >
> >     I also think it is the right thinking to allow libraries and more 
> > specifically ABI breaks between releases. But those should never 
> > occur in a maintenance release, which is what happened here if I got 
> > the gist of it. If the break would be between 3.4.x and 3.6.0 it 
> > would be fine by me. But breaking between 3.6.0 and 3.6.1 should not 
> > happen. I consider this an issue that must be fixed - but the change 
> > should most certainly happen with a version beyond 3.6.
> >
> >     And just additionally my 2 cents. Please always consider that 
> > although the download rates of Wireshark are mind-blowing and 
> > wonderful, the adoption within companies might be even greater with 
> > special build versions. There exists many reasons for those versions, 
> > be it not enough resources available to bring changes to mainline or 
> > having code and adaptations which are for whatever (legal mostly) 
> > reasons not able to be publicly available. Changes like these i would 
> > see as a risk to those practices, and one of the reasons Wireshark 
> > has such a good standing within the community are our policies for 
> > long-time stability and maintainability.
> >
> >     Just my own thoughts on this.
> >     cheers
> >     Roland
> >
> >     Am Do., 20. Jan. 2022 um 13:42 Uhr schrieb Bálint Réczey 
> > <balint@xxxxxxxxxxxxxxx <mailto:balint@xxxxxxxxxxxxxxx>>:
> >
> >         Hi All,
> >
> >         João shared his opinion about the project's commitment to 
> > maintain
> >         stable shared library ABI within stable branches:
> >         https://gitlab.com/wireshark/wireshark/-/issues/17822 
> > <https://gitlab.com/wireshark/wireshark/-/issues/17822>
> >
> >         I believe the current practice is reasonable and beneficial 
> > enough for
> >         many parties to warrant the work, but I could be wrong.
> >
> >         Comments are welcome.
> >
> >         Cheers,
> >         Balint
> > ___________________________________________________________________________
> >         Sent via:    Wireshark-dev mailing list 
> > <wireshark-dev@xxxxxxxxxxxxx <mailto:wireshark-dev@xxxxxxxxxxxxx>>
> >         Archives: https://www.wireshark.org/lists/wireshark-dev 
> > <https://www.wireshark.org/lists/wireshark-dev>
> >         Unsubscribe: 
> > https://www.wireshark.org/mailman/options/wireshark-dev 
> > <https://www.wireshark.org/mailman/options/wireshark-dev>
> >                       mailto:wireshark-dev-request@xxxxxxxxxxxxx 
> > <mailto:wireshark-dev-request@xxxxxxxxxxxxx>?subject=unsubscribe
> >
> >
> > ___________________________________________________________________________ 
> >
> > Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________ 
>
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe