On Wednesday 22 February 2012 18:33:02 Alexander Neundorf wrote: > On Tuesday 21 February 2012, Christophe Giboudeaux wrote: > > On Monday 20 February 2012 19:38:37 Sune Vuorela wrote: > > > On Saturday 18 February 2012 18:45:54 Alexander Neundorf wrote: > > > > On Saturday 18 February 2012, David Faure wrote: > > > > > Can we PLEASE get rid of the version number in the install > > > > > directory? > > > > > It's way more trouble than any benefit it might bring. > > > > > > > > > > If one day we want co-installable incompatible releases, > > > > > > > > I want to have co-installable releases right from the beginning. > > > > > > I don't. It makes no sense what so ever to have it, and it is only > > > giving > > > headaches to the users of ecm. > > > > Agreed. and I fully support removing this versioned prefix. I consider > > this > > a showstopper (ie: I would invite people to stay away from ecm to avoid > > headaches). > > > > The past experiences with kdepimlibs and kdebase-workspace have been > > complete failures and both were fixed. (I fixed kdepimlibs in 2009 and > > Thiago fixed kdebase-workspace last year). > > > > The reason is quite simple: we don't bump the version after each feature > > or > > In e-c-m the version *must* be increased for every added feature (in a > release).
Erm.. You noticed that's it's currently 0.0.3 and that it already has 2313
commits, right ?
Anyway, the issue is not the version but the installation prefix.
>
> > bug fix and if someone has a build error, the answer is "update
> > thisModule"
> > rather than "update thisModule to X.Y.Z version."
> >
> > Additionally, this requires bumping the minimum version in the depending
> > module. You're then facing two issues:
> > - You're not supposed to try each version to find the right one,
>
> ?
> When using a feature, you have to know in which version it is.
> We'll need to provide a way to make this easy to find out.
... and if you don't know, you simply use the latest.
> > - You can't use find_package(FOO) without the version since cmake will not
> > check whether his cache should be refreshed.
>
> Yes, and in general you shouldn't, since every new version will have new
> stuff.
>
Well, and ? You won't reinvent the wheel each time you bump the version. Once
again, using the latest will be the wisest choice.
> > Concurrent installation are still possible using different install prefix
> > and just playing with CMAKE_PREFIX_PATH.
>
> I may think about leaving the patch-level version number out, but beside
> that it will stay versioned.
>
> So that the patch level version is kept for bugfixes, which should be
> compatible, and the minor version can contain new features.
> Whatever feature you use, you have to make sure using the minimum required
> version that you get a proper version of e-c-m.
Once again, this is unrelated to the installation path.
>
> Everything you describe is no reason against versioned installs.
and what you describe is no good reason to keep it.
>
> Remember, e-c-m is no typical KDE package, not at all.
> It is intended to be used by any projects, KDE, Qt, gtk, EFL, XCode,
> whatever.
and they'll be facing the same issue our developers had with versioned
kdepimlibs and kdebase-workspace (and will most certainly have with ecm if the
current behaviour is kept).
>
> You are correct that to use it properly, you need to use the minimum
> required version.
> There is absolutely no way around this, and this is completely independent
> from whether the install dir is versioned or not.
There I agree, we need a minimum version, but that's not a reason for keeping
set(SHARE_INSTALL_DIR share/extra-cmake-modules-${ECM_VERSION})
>
> If you use some feature from a released e-c-m version, you have to check in
> which version this feature has been introduced.
and again, the installation prefix is of no use for this.
What do you think packagers will do ? provide different versions or use the
last one ?
We (packagers) have absolutely no interest in having several versions on the
same application since that means:
- more maintenance,
- more space,
- more potential packaging issues.
Having several parallel installations make sense only in a few cases:
- Libraries when their soname is changed
- Very specific applications that are not runtime compatible (example:
PostgreSQL)
ecm enters in none of these categories.
Christophe
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
