After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 521720 - Is checking evolution per version justified
Is checking evolution per version justified
Status: RESOLVED WONTFIX
Product: evolution-sharp
Classification: Deprecated
Component: bindings
unspecified
Other All
: Normal minor
: ---
Assigned To: evolution-sharp-maint
evolution-sharp-maint
gnome[unmaintained]
Depends on:
Blocks:
 
 
Reported: 2008-03-11 06:33 UTC by Maciej (Matthew) Piechotka
Modified: 2014-08-30 00:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A simple patch (1.29 KB, patch)
2009-02-04 23:18 UTC, Maciej (Matthew) Piechotka
rejected Details | Review
The patch I meant (1.41 KB, patch)
2009-02-06 13:21 UTC, Maciej (Matthew) Piechotka
rejected Details | Review
0001-Remove-unnecessaryrestrictions-on-e-d-s.patch (1.86 KB, patch)
2009-07-25 01:21 UTC, Maciej (Matthew) Piechotka
none Details | Review

Description Maciej (Matthew) Piechotka 2008-03-11 06:33:24 UTC
In evolution# each version(1.10.x etc.) is checked separetly. Hence each time I upgrade evolution I have to upgrade evolution# [I am not taking about rebuilding - I need to upgrade] despite the fact that is is unlikely that the API is broken. Since I use gentoo with test gnome and the bindigs are upgraded less often it is very inconvinient for me.

Hence if evolution# check version of evolution please do it in such way:
- If 1.x -> enable basic features
- If 1.(x+2) -> enable additional features
...
- If 1.(x+2n) -> eable additional features
- If bigger threat as if it was 1.(x+2n)

If no additional features are enabled just check for the version bigger or equal 1.x.

Other information:
Comment 1 Maciej (Matthew) Piechotka 2009-02-04 23:18:57 UTC
Created attachment 127969 [details] [review]
A simple patch
Comment 2 Johnny Jacob 2009-02-06 12:18:10 UTC
(In reply to comment #1)
> Created an attachment (id=127969) [edit]
> A simple patch
> 

Hmm.. Removing error message is not a good idea :). We should somehow get the API versions of the dependent libs and decide based on that. 

Thanks.
Comment 3 Maciej (Matthew) Piechotka 2009-02-06 13:21:30 UTC
Created attachment 128092 [details] [review]
The patch I meant

Sorry - I make a typo - I meant to include everything newer then  the last version in it. Ie. If last 'supported' version is 2.24 and user tries to build against 2.26 than it should be threated as 2.24.
Comment 4 Johnny Jacob 2009-02-10 16:49:42 UTC
(In reply to comment #3)
> Created an attachment (id=128092) [edit]
> The patch I meant
> 
> Sorry - I make a typo - I meant to include everything newer then  the last
> version in it. Ie. If last 'supported' version is 2.24 and user tries to build
> against 2.26 than it should be threated as 2.24.

The issue is , if we allow this then 0.19.x tarball would be compatible with EDS 4.x and all the future versions of EDS which we don't want to . Because the API/ABI would change. We would need a better solution for this.
Comment 5 Maciej (Matthew) Piechotka 2009-02-10 18:51:12 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Created an attachment (id=128092) [edit]
> > The patch I meant
> > 
> > Sorry - I make a typo - I meant to include everything newer then  the last
> > version in it. Ie. If last 'supported' version is 2.24 and user tries to build
> > against 2.26 than it should be threated as 2.24.
> 
> The issue is , if we allow this then 0.19.x tarball would be compatible with
> EDS 4.x and all the future versions of EDS which we don't want to . Because the
> API/ABI would change. We would need a better solution for this.
> 

If a API/ABI change in a manner that breakes the compatibility then, I'm nearly sure, it will no longer be marked as evolution-data-server-1.2! If will be called for example evolution-data-server-4.0.

pkg-config have such mechanism built-in so there is no need to have it doubled in scripts (especially in manner thet is hard for GNOME beta users - or GNOME developers).
Comment 6 Matthew Barnes 2009-07-23 17:32:54 UTC
The -1.2 suffix is a meaningless artifact that we're stuck with.  The API/ABI version is indicated by the shared object name.  e.g. libecal-1.2.so.7.2.1

pkg-config does not deal with API/ABI versioning, only package versions.  But we are mindful about avoiding API/ABI breaks and changing the shared object name when a break is unavoidable.  Between that and the version check macros that libedataserver now supplies [1], there should be no need to individually test for current and future releases.

[1] http://library.gnome.org/devel/libedataserver/stable/libedataserver-Version-Information.html
Comment 7 Maciej (Matthew) Piechotka 2009-07-25 01:21:43 UTC
Created attachment 139192 [details] [review]
0001-Remove-unnecessaryrestrictions-on-e-d-s.patch

Patch updated against master.
Comment 8 Mario Manno 2010-05-16 22:34:50 UTC
Patch works fine. Please note this bugs stops modern distros from including evolution-sharp as a package.
Comment 9 André Klapper 2014-08-30 00:08:40 UTC
evolution-sharp has not seen any code changes since May 2009:
https://git.gnome.org/browse/archive/evolution-sharp/log/

This project is not under active development anymore and got recently archived
in GNOME Git.
It is currently unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this bug report in the future if anyone
takes the responsibility for active development again.