Hi, I would like to add that there are other much bigger frameworks which have a lot more resources at hand and also have one single version under which all of the many submodules are released:
Java (Java 6, Java 7, Java 8, ...) https://en.wikipedia.org/wiki/Java_version_history .NET (3.0, 3.5, 4.0, 4.5, ...) https://en.wikipedia.org/wiki/.NET_Framework An application based on one of these frameworks needs to reference only one version. Each framework is released together and it is installed as one package. Gregor On 29/04/15 20:34, David Faure wrote: > On Tuesday 28 April 2015 12:17:00 Christian Mollekopf wrote: >> Our dependency tree is now indeed reduced, but if we want to update a >> single library, we are forced to update all libraries, due to the >> version-lock caused by periodic bumping of dependencies. > > You say at the end of the mail that you are using (or you plan to use only) 6 > frameworks. Having to update 6 frameworks together doesn't seem like a huge > amount of work to me. > > OK, 11, when including the PIM modules which AFAIU aim at becoming frameworks. > >> Similarly, requirements are bumped as the requirements increase, making it >> entirely possible that some low-level libraries can remain the same while >> others are updated. > > This would lead to an awful "version zoo". > KIO 5.7 requires KXMLGui 5.5 and KCoreAddons 5.4, but actually KXMLGui 5.5 > requires KCoreAddons 5.5 so overall KCoreAddons 5.5 is required, etc. etc. > Multiply this by 64 frameworks and you have a horrible confusion for everyone > everywhere. > >> I think our requirements can be split into two parts: >> * No automatic version-bumping of dependencies: This harms us the most >> because it forces us to update everything when updating something. It's >> not a problem in Tier1 frameworks, but I've seen some doing it (khtml), >> so I hope it's not a policy and we can do it differently in PIM. > > Everything under frameworks/ is released together and with the same version > number. This includes any PIM-related frameworks. > On the other hand if you mean PIM-related stuff outside of frameworks/, then > they will have a different release schedule and therefore a different > versioning scheme I assume. > >> * A version number that follows changes and not time: As I understand >> version numbers are currently bumped periodically because we anyways >> lack the manpower for release-management, and since changes usually >> happen, the version is just periodically bumped before each release. >> This seems to prevent release-management to happen though, where the >> version number is a vital tool for planning what ends up in what >> version. So my question would be whether we could move certain >> frameworks from that time-boxing model to a feature-boxing model, >> allowing the releases to be somewhat planned. > > The whole point of the monthly release cycle is that bugfixes see the light > of > day in the coming month, not 6 months later. > So if we cannot release a new version because no new feature happened (is > this > what you mean?), it would break this concept. Or if you mean releasing but > with a different version number depending on whether there were only bugfixes > or also features, then I have to disagree for many reasons, including > - the version zoo mentionned above > - the lack of a clear-cut line between bugfixes and features > - the need for a manual decision in 62 frameworks > - the fact that the workflow for frameworks (master always stable and > releasable) does not require a distinction between bugfixes and features, > like > the KDE4 workflow required. > >> I assume the current versioning is happening so noone has to maintain >> the individual version-numbers > > That is one reason, but not the only reason. Making the release dude's life > (i.e. my life) harder is one thing I'll fight against, but the other reason > is > that a version zoo also makes things harder for everyone else: packagers, > developers and users. > >> Initially I'd like to stop the automatic dependency bumping, the rest >> can IMO wait some more, that's something that can be solved on the PIM >> side, but I need to know if there are policies regarding that, or if >> some frameworks just choose to do that out of laziness (aka lack of >> manpower). >> The release-management I'd try first on kimap, which is not yet a >> framework, and where I'm maintainer, so my question would be whether you >> somehow rely on all frameworks have the same version, and how we could >> fix that. > > I'm confused by what you're saying here. If it's not a framework, it's not a > framework, you can release whichever way you want. But once it's a framework, > it will be released like everything else, with automatic version number > increases. > >> If it goes well with kimap, I'd then just approach the >> individual maintainers. > > There is no point in doing that. They don't release the frameworks. > I do. I release them all. > >> * PIM (not yet part of frameworks) >> ** KCalendarCore >> ** KCalendarUtils >> ** KMIME >> ** KIMAP >> ** KContacts >> >> * Current Frameworks >> ** ECM >> ** KCoreAddons >> ** KConfig >> ** KI18n >> ** KDELibs4Support >> ** KCodecs > > Please keep in mind that this is only a very small subset of the overall set > of frameworks. So if you think that the version zoo from these 11 would be > manageable, it doesn't mean it would be for the 75 frameworks we'll end up > with (guesstimate from the current 62 plus a bunch of upcoming pim > frameworks). > > Look at it another way. Does QtNetwork 5.4 say that it requires QtCore 5.2 or > later ? Does QtSvg 5.4 say that it requires QtGui 5.3 or later ? > No. You install Qt 5.4, you get everything 5.4. > > The same happens with frameworks, you install KF 5.9, all the modules are 5.9. > This is not laziness. It's the only way to have something that a human (all > humans) can wrap their head around, to avoid a complex version matrix with 75 > frameworks each requiring a different version of the 1-to-20 frameworks they > depend on. > _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
