Versioning of Frameworks

[Gregor Mi]

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