Versioning of Frameworks

Tue May 5 09:33:03 UTC 2015

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.
* 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.

> > 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.
> 

I guess that becomes the question.

If I cannot version a library myself, I IMO don't have the tools I need
to develop a high quality library.
And in this case frameworks becomes too restrictive for me, and I will
therefore have to keep libraries out of it.
That's fine by me, but not what I expected frameworks to be. I expected
frameworks to be an inclusive umbrella
for kde libraries that can be used by third parties. 

This becomes a problem however, because the KDE PIM team would generally
like to have all libraries
under the frameworks umbrella, because we have libraries that solve
specific needs that are valuable to third parties,
and that's how frameworks was marketed. So I think it's a pity if we
cannot do that for the versioning reason.

> > * 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?), 

Bugfix releases can be done at all times. If a library has no new
features for 2 years it may
go from 1.6.0 to 1.6.15, but then you see immediately what's going on.

> 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. The result of
that release management will be a new version
in the master branch which can essentially be blindly packaged.

> > 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.
> 

I fully agree we shouldn't make your life harder, but I also think it
shouldn't become any harder.
I'm certainly not suggesting that you yourself maintain individual
version numbers for 62 frameworks.
With the version zoo argument I simply have to disagree. It makes the
life of developers easier, users don't have to care about it at all and
from packagers I get to hear both, but frankly, if it can be done for
the rest of the libraries available in linux, it ought to be possible
for frameworks as well.

> > 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.
> 

Whether it becomes a framework or not depends largely on this matter.

> > 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.
> 

Yes, but releasing frameworks shouldn't have anything to do with
assigning version numbers.
Maintainers should be releasing their libraries.

> > * 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).
> 

I understand that we cannot afford to this for every framework, my
problem is that the current
way actually prevents anyone from versioning their library, IMO,
properly.

> 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.
> 

Which is not ideal either, but it's their choice and that's fine. Also,
frameworks is a more diverse set of libraries that it IMO makes sense to
treat libraries individually, where qt is still somewhat treated as a
single library.

> 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.

I don't think what you actually have to wrap your head around as a user
becomes a whole lot more complex,
because you continue to use the latest version of each library if you
wish to do so.
With the current versioning scheme libraries are timestamped, and not
actually versioned, which I think results
in lower quality libraries, hinders portability, and is generally a
whole lot less useful than an actual version number.

To conclude, I understand the manpower issues and I'm not trying to make
it more difficult for you, but if people are prevented from developing
their library in a more controlled and portable fashion and do some
release management, then frameworks for me becomes a whole lot less
desirable.

Cheers,
Christian