Versioning of Frameworks

[Alexander Neundorf]

On Tuesday, May 05, 2015 11:33:03 Christian Mollekopf wrote:
> Hey David,
> 
> Sorry for the late response.
> 
> On Wed, Apr 29, 2015, at 08:34 PM, 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.
> 
> I'm typically not at the receiving end of backporting issues, therefore
> I work with what I am told.
> 
> I also simplified the problem too much, there are also some other points
> to consider:
> * If I have to pull in a new feature release into my system, that
> imposes the threat of additional instability and new bugs introduced. I
> typically don't want that on a server, so I only do bugfix upgrades as
> far as possible. If this bugfix now pulls in a whole set of new feature
> releases, I simply cannot afford to do that update for the risk it
> imposes. So it's essential to keep the dependency tree to a minimum in
> an enterprise environment, simply to avoid unnecessary change.

Exactly. At work we depend on a small number of additional libraries (BSD-
licensed ones). We update them only if they fix something we really need. When 
doing that, we check what else has changed there. If a bugfix in one of those 
libs would require us to update 5 other libs too (because they happened to 
increase their version number), that would be a major problem for us, because 
it would mean a lot of unnecessary checking what has changed.

> * A version number is IMO an essential tool for doing planned releases
> and to do some release engineering. Frameworks as it is now takes that
> tool away from me as the maintainer of a potential framework.
> 
> > OK, 11, when including the PIM modules which AFAIU aim at becoming
> > frameworks.
> 
> And all the dependencies of those frameworks that they pull in (assuming
> they are also just blindly bumped to the latest and greatest).
> 
> > > 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 don't know, to me that's just how versioning and dependencies work. I
> have hundreds of libraries installed on my system,
> and they all have different version numbers, and that's IMO exactly how
> it should be, because otherwise
> that version number essentially becomes a timestamp which is a whole lot
> less valuable.


+1.
That's what we (KDE) somehow decided for when saying we'll split it all into 
frameworks, but then didn't go the wole way, but we pretend it's all 
independent libraries but still they all depend on the latest version of all 
other libs. Nobody wanted to agree to this when I raised that issue two or 
three years ago: if we do the split properly, we get "dependency hell", that's 
simply the cost of it. But it has its good sides too, as you point out.

...
> > 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
> 
> I absolutely understand the lack of manpower, and I appreciate that you
> do all the release work.
> However I don't suggest that you do manual decisions for 62 frameworks.
> Either there is a maintainer that
> is doing that work, or there is none and you keep it a simple as it
> works for you.
> 
> What the regular releases IMO should be doing, is to take the latest
> version from the "always releasable" master branch,
> and be done with it (and that means not touching the library version,
> because that's not the responsibility of the person who
> releases, it's the responsibility of the maintainer of the library).
> 
> > - 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'm not suggesting to change that, I'm asking to not take the library
> version number away from maintainers
> that need it as a vital tool for their release management. 

I'm afraid here we have the problem, many libraries are missing these 
maintainers.


Alex