[E-devel] Fwd: [Proposal] release schedule and version numbering
Patch attached. As usual, comments are welcome Regards, Albin -- Forwarded message -- From: Carsten Haitzler Date: Wed, Apr 15, 2009 at 3:52 AM Subject: Re: [Proposal] release schedule and version numbering To: Albin Tonnerre Cc: Gustavo Sverzut Barbieri On Tue, 14 Apr 2009 18:59:40 +0200 Albin Tonnerre said: THIS... is why i have not wanted to release and force sonames. it totally irks me to have "libblah 2.0" and the actual lib.so is blibblah.so.7.0 ... its totally horrible. pre 1.0 we reserve the right to break .so's at will and we keep our .so's at the version of the software to stop the inconsistency in release ver, package ver and .so ver. if this conflicts with debian policy... then i am afraid we have a e vs debian policy conflict and that will not be resolved until we release 1.0... what i might consider is renaming the libname instead of libevas.so.0.9.9 libevas-pre1.so.0.9.9 libevas-pre2.so.0.9.9 etc. and on release we remove the -preXXX and go to libevas.so.1.0.0 thats my "compromise" :) > Hi, > > With the idea of having freezes and a release schedule, I'd really like to get > proper version bumps when there are API changes in the core libraries. > > I know this idea hasn't been very popular in the past, mostly because the > devs don't want to bother with this, which is something I understand. > > However, as you may know, I maintain the e17 packages in debian. > Part of this job implies manually changing libraries SONAME when the > interfaces change, which implies some patching on every single snapshot > I'm uploading (and which breaks the interface, of course). As I'm doing > it for debian anyway, I think I might do this is the SVN just as well, if you > agree. > > What I'm doing currently is the following: use > '-release @package_vers...@$(MINOR)' instead of > '-version-info @version_info@', in LDFLAGS, so that the generated SONAME > looks like the following: libevas-0.9.9.050$(MINOR).so, with MINOR being > whatever you feel like using (I use letters, for example) > > The immediate benefits - besides me being happy - is that it would be easier > to detect when users are experiencing bugs due to API changes. Imagine a > user links an app against evas, then updates evas, which has changed SONAME: > either he has the old evas installed and everything's fine. If he has not kept > the old version, the app won't even launch as the lib will be missing, where > he previously would have experienced crashes or random behaviour. So I > do think that would help sometime :) > > Regards, > Albin > Index: ecore/src/lib/ecore_win32/Makefile.am === --- ecore/src/lib/ecore_win32/Makefile.am (revision 40092) +++ ecore/src/lib/ecore_win32/Makefile.am (working copy) @@ -36,7 +36,7 @@ @EVAS_LIBS@ \ @EINA_LIBS@ -libecore_win32_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ +libecore_win32_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ -release @ecore_win32_release_info@ endif Index: ecore/src/lib/ecore_wince/Makefile.am === --- ecore/src/lib/ecore_wince/Makefile.am (revision 40092) +++ ecore/src/lib/ecore_wince/Makefile.am (working copy) @@ -26,7 +26,7 @@ $(top_builddir)/src/lib/ecore/libecore.la \ @EINA_LIBS@ -libecore_wince_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ +libecore_wince_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ -release @ecore_wince_release_info@ endif Index: ecore/src/lib/ecore_config/Makefile.am === --- ecore/src/lib/ecore_config/Makefile.am (revision 40092) +++ ecore/src/lib/ecore_config/Makefile.am (working copy) @@ -27,7 +27,7 @@ include_HEADERS = \ Ecore_Config.h -libecore_config_la_LDFLAGS = -version-info @version_info@ +libecore_config_la_LDFLAGS = -version-info @version_info@ -release @ecore_config_release_info@ #config_DATA = $(DB) #configdir = $(pkgdatadir) Index: ecore/src/lib/ecore_x/Makefile.am === --- ecore/src/lib/ecore_x/Makefile.am (revision 40092) +++ ecore/src/lib/ecore_x/Makefile.am (working copy) @@ -24,7 +24,7 @@ libecore_x_la_LIBADD = $(DEP) \ @EINA_LIBS@ -libecore_x_la_LDFLAGS = -version-info @version_info@ +libecore_x_la_LDFLAGS = -version-info @version_info@ -release @ecore_x_release_info@ libecore_x_la_DEPENDENCIES = $(DEP) Index: ecore/src/lib/ecore_job/Makefile.am === --- ecore/src/lib/ecore_job/Makefile.am (revision 40092) +++ ecore/src/lib/ecore_job/Makefile.am (working copy) @@ -23,7 +23,7 @@ @EINA_LIBS@ \ @EVIL_LIBS@ -libecore_job_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ +libecore_job_la_LDFLAGS = -no-undef
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Wed, 15 Apr 2009, Albin Tonnerre wrote: > Patch attached. As usual, comments are welcome in ecore, is it really necessary to have a release-info for each module ? Vincent > > Regards, > Albin > > -- Forwarded message -- > From: Carsten Haitzler > Date: Wed, Apr 15, 2009 at 3:52 AM > Subject: Re: [Proposal] release schedule and version numbering > To: Albin Tonnerre > Cc: Gustavo Sverzut Barbieri > > > On Tue, 14 Apr 2009 18:59:40 +0200 Albin Tonnerre > said: > > THIS... is why i have not wanted to release and force sonames. it totally irks > me to have "libblah 2.0" and the actual lib.so is blibblah.so.7.0 ... its > totally horrible. pre 1.0 we reserve the right to break .so's at will and we > keep our .so's at the version of the software to stop the inconsistency in > release ver, package ver and .so ver. > > if this conflicts with debian policy... then i am afraid we have a e vs debian > policy conflict and that will not be resolved until we release 1.0... > > what i might consider is renaming the libname > > instead of libevas.so.0.9.9 > libevas-pre1.so.0.9.9 > libevas-pre2.so.0.9.9 > etc. > > and on release we remove the -preXXX and go to libevas.so.1.0.0 > > thats my "compromise" :) > >> Hi, >> >> With the idea of having freezes and a release schedule, I'd really like to >> get >> proper version bumps when there are API changes in the core libraries. >> >> I know this idea hasn't been very popular in the past, mostly because the >> devs don't want to bother with this, which is something I understand. >> >> However, as you may know, I maintain the e17 packages in debian. >> Part of this job implies manually changing libraries SONAME when the >> interfaces change, which implies some patching on every single snapshot >> I'm uploading (and which breaks the interface, of course). As I'm doing >> it for debian anyway, I think I might do this is the SVN just as well, if you >> agree. >> >> What I'm doing currently is the following: use >> '-release @package_vers...@$(MINOR)' instead of >> '-version-info @version_info@', in LDFLAGS, so that the generated SONAME >> looks like the following: libevas-0.9.9.050$(MINOR).so, with MINOR being >> whatever you feel like using (I use letters, for example) >> >> The immediate benefits - besides me being happy - is that it would be easier >> to detect when users are experiencing bugs due to API changes. Imagine a >> user links an app against evas, then updates evas, which has changed SONAME: >> either he has the old evas installed and everything's fine. If he has not >> kept >> the old version, the app won't even launch as the lib will be missing, where >> he previously would have experienced crashes or random behaviour. So I >> do think that would help sometime :) >> >> Regards, >> Albin >> > > -- > Ce message a ?t? v?rifi? par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a ?t? trouv?. > Message d?livr? par le serveur de messagerie de l'Universit? d'Evry. > > -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 7:38 AM, Vincent Torri wrote: > > > On Wed, 15 Apr 2009, Albin Tonnerre wrote: > >> Patch attached. As usual, comments are welcome > > in ecore, is it really necessary to have a release-info for each module ? > I think it's better, unless you want to force a SONAME change upon all the 18 libs every time one of them changes. That would force a lot of unneeded recompiles for programs who rely on parts which haven't changed (for example, if you break the ecore_win32 API, you sure don't want all the libs to change SONAME) Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, 16 Apr 2009, Albin Tonnerre wrote: > On Thu, Apr 16, 2009 at 7:38 AM, Vincent Torri wrote: >> >> >> On Wed, 15 Apr 2009, Albin Tonnerre wrote: >> >>> Patch attached. As usual, comments are welcome >> >> in ecore, is it really necessary to have a release-info for each module ? >> > > I think it's better, unless you want to force a SONAME change upon all the 18 > libs every time one of them changes. That would force a lot of unneeded > recompiles for programs who rely on parts which haven't changed (for > example, if you break the ecore_win32 API, you sure don't want all the libs to > change SONAME) in that case, is it good to specify both -release and -version-info in _LDFLAGS ? Vincent -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 9:57 AM, Vincent Torri wrote: > > in that case, is it good to specify both -release and -version-info in > _LDFLAGS ? > I think it's mostly a matter of taste. Keeping both doesn't hurt much IMHO, and all you'll have to do when there's a real release is remove the '-release' part. Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 6:25 PM, sda wrote: > hi, > > just FYI - general rules for rpm packaging: > http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html > brief summary of packaging conventions which confirms to the LSB could > be reviewed below (distro-specific!): > http://en.opensuse.org/Packaging > > the offer above is about to change NAME - ???!!!. if (when) we settle > the exact E-svn-revision numbers to be packaged and available for all > the info like "RC", "Alpha", "Beta", "Fix1 to RC" etc shoulg go to the > Changelog or Summary (as a last resort). > I'm sorry, but I don't understand what your point is. Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 7:00 PM, Albin Tonnerre wrote: > On Thu, Apr 16, 2009 at 6:25 PM, sda wrote: >> hi, >> >> just FYI - general rules for rpm packaging: >> http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html >> brief summary of packaging conventions which confirms to the LSB could >> be reviewed below (distro-specific!): >> http://en.opensuse.org/Packaging >> >> the offer above is about to change NAME - ???!!!. if (when) we settle >> the exact E-svn-revision numbers to be packaged and available for all >> the info like "RC", "Alpha", "Beta", "Fix1 to RC" etc shoulg go to the >> Changelog or Summary (as a last resort). >> This patch is not about changing package names. It's about getting proper SONAME changes when devs break the API or the ABI. What happends to the package names is not releveant to this, as this is the maintainer's decision. Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Fri, Apr 17, 2009 at 1:50 AM, sda wrote:
> as we recently discussed on IRC the results of the patch will lead th the
> changing of a SONAME. illustration is below.
>
Please note that this was also explained in my initial mail.
> current data:
>
>> objdump -x /usr/lib/libeina.so.0.0.1 | grep -i soname
> SONAME libeina.so.0
>
> as we may assume after this patch the changes will be:
>
>> objdump -x /usr/lib/libeina.so.0.0.1 | grep -i soname
> SONAME libeina-PREFIX.so.0
>
> where "PREFIX" is some thing i definitely dislike because here's the
> Novell/openSUSE "Shared Library Packaging Policy":
> http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy
>
> rules are strict and straight forward (like):
>
> * SONAME - the name (query for it using objdump -x libfoo.so.1 | grep SONAME)
> a shared library is referred as by the dynamic loader.
>
> * Shared libraries in /lib{,64} or /usr/lib{,64} shall be packaged into
> rpms whose name is "lib" + $NAME + $NUM.
>
SONAME is *NOT* necessarily libfoo.so.X. The use of -release is valid. I don't
want to turn this into a flame, but your distro should not rely on
everything using
-version-info only to create package names.
> * $NAME is formed by cutting off the prefix "lib" and suffix ".so.*" from the
> SONAME
>
> * $NUM contains only decimal digits and underscores.
>
> * $NUM is equal to the shared library SONAME number with dots replaced
> by underscores.
>
> in this case the patch will increase the repository maintenance by
> manually substituting values in "Name:" and "BuildRequires:" fields of a
> spec files.
>
> patch is completely useless for all projects developed/maintained in OBS
> (openSUSE Build Service) because Build Service provides automated
> rebuild of all packages which depend on the selected one if sources of
> the selected package are changed (this is done by automatic control of a
> "Release:" field and conservative approach for the dependencies -
> they'd rebuild if the values of "Version"/"Release" are changed which is
> a sign that sources are modified somehow).
>
As per IRC too, it's useless ONLY for OBS, which uses a pessimistic
approach and rebuilds
all the reverse depenencies when there's an update to a library (if my
understanding is
correct). So you're basically proposing to drop the change only before
your particular
build system allows you to avoid it. But please think about people
which do not use OBS,
and especially people who compile directly from source
> so i wote for "$NUM" changes and suppose that it's a way better than
> changes of a "$NAME". all the info about "rev1", "rev2", "RC", "alpha",
> etc. should be visible on E official sites, in Changelog or in Summary.
I did not write a patch changing this NUM because raster he opposed to
this, as he wants to
keep libfoo.so.1 for the final release (as per the email I forwarded).
Raster, gustavo, other devs: what do you think ? Is it sane enough to
get merged ? (note
that the idea behind this is to increment the @release_info@ on each
API/ABI change, not
globally on every release like this one)
Regards,
Albin
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Fri, 17 Apr 2009 12:27:34 +0400 sda said: > please look above and let's find some sane solution. API/ABI change > should in theory change SONAME (i.e. libfoo.so.0.1 -> libfoo.so.0.2) > but ... we're in a real world and we're working with svn. why not to use > changes of Version along with the proposed above schema on Version > naming? because the only way to break abi with version is to go libX.so.1.x.x -> libX.so.2.x.x ie increase MAJOR number. i do NOT ant to change the version of the lib as when evas/ejde/whatever get released i want them to be: libevas.so.1.0.0 and AFTEr 1.0.0 relase we will use so version for api breaks - and the evas RELEASE will also show it. the source release version, package version ANd lib so version will/should MATCH! i want them to MATCH! i want it to all be simple and consistent so it's easy to know whats intstalled, and what will or wont work with it. until 1.0.0 happens there is NO WAY to break an abi WITHOUT changing soname i.e. libX-pre01.so.x.x.x -> libX-pre02.so.x.x.x etc. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
