Versioning of Frameworks

[Christian Mollekopf]

On Tue, May 5, 2015, at 05:38 PM, Martin Gräßlin wrote:
> On Tuesday 05 May 2015 17:30:05 Mario Fux wrote:
> > Am Dienstag, 05. Mai 2015, 13.46:16 schrieb Martin Gräßlin:
> > > > If master is always releasable, you should indeed only merge into master
> > > > with a change of a version number.
> > > > If you don't want to maintain different versions for whatever reason
> > > > (and I think that's an entirely reasonable choice),
> > > > you can continue to automate this version bump. As long as I can exclude
> > > > my library from the automatic version bumping,
> > > > I see no problem at all. Having an automatic version bump as a
> > > > requirement to be a framework is the problem IMO.
> > > 
> > > ok, I start to understand what you want to get: two different ways of
> > > releasing frameworks. I think that's a very bad idea for obvious reasons I
> > > hope I do not have to bring up here.
> > 
> > Ok, they are not that obvious too me. Wouldn't it be possible to add
> > something like maintainerManagesVersionOnItsOn=false to a file in all the
> > frameworks (isn't there already a file in each frameworks for stuff like
> > platforms, etc.?) and modify the release-scripts (David or anybody who
> > knows these scripts) once so that these scripts check this variable.
> > 
> > So if it's set to false and most current maintainer seem to prefer not to do
> > version bumps on their own the release scripts would bump the version
> > number and do all the stuff as they do now. If the variable was set to true
> > these scripts wouldn't bump the version numbers and just use the version
> > numbers as set by the maintainer?
> > 
> > Or is this just naive thinking from my side that it's "that easy"?
> 
> It would mean the end to the "product" frameworks we provide today. We
> would 
> no longer release "60 addon libraries to Qt", but well maybe one month
> 20, the 
> next one 40 and every one would have a different number of frameworks 
> included.

You can continue to release all frameworks every n months, if nothing
has changed in the library the version number would just stay the same
for that library. Every release would therefore be a snapshot of the
latest
released frameworks.

> The versioning would be a complete mess: each framework having
> a 
> different version number, some doing bug fix releases, some don't. 

...that "complete mess" is just actual versioning instead of a timestamp
that is applied to everything.

To me "frameworks" is on one side a the umbrella term for all
frameworks,
and on the other hand a distribution of kde-related libraries.
What it seems to be treated as largely is one gigantic library
consisting of 62
submodules, which is IMO a shame since so much work has been put into
splitting these modules up, and making these libraries reusable by third
parties.
So I don't really understand why we now have to continue treating all
libaries
within frameworks as something special instead of just like any other
library out
there.

>What would 
> it mean if I have KIO in 5.10 and KWindowSystem in 5.10? Is that from the
> same 
> month or did KIO skip May and KWindowSystem the June release?

How do you do it for linux distributions? You look it up.
If there is a need for a frameworks version then that can be kept,
setting that as the library version is the problem.

> Bug investigation would become close to impossible, just imagine asking the
> user 
> to provide each of the versions of all dependencies of e.g. plasmashell.

A user either provides the frameworks version, which can be resolved to
the library version,
or quite simply the library version. There's shouldn't be anything
"special" about libraries in
frameworks, and they also don't have to be treated that way. This
process works
for the other hundereds of libraries I have on my system and it would
work for frameworks.

> What 
> is the message we give to the outside concerning release process and 
> versioning? The best I can get from that is "we have no clue what we are 
> doing". And users are currently already complaining that there is no
> "KDE" 
> anymore, but that there are now three different version numbers for 
> frameworks, plasma and applications. If we go with each framework a
> different 
> number they have a point if they say that one cannot follow that.
> 

That seems to work alright for linux distributions though. First off,
noone needs to follow that. Developers either use a library or they
don't
and to users a library is nothing more than an implementation detail.
Noone tracks versions for all libraries available, and distributions can
just
pickup the latest snapshot.
Second, frameworks can still be released with a "frameworks-version"
number
if we see any value in that. Just like kubuntu is called 15.04 but
doesn't therefore
put that version into every library it ships.

The point is that a version number is a tool for developers to
communicate what is going on.
A tool that is well understood, and can be automatically processed by
buildsystems and
package managers. By turning the version number into a timestamp
(increment every n days),
that tool is rendered largely useless, other than signifying that
something may have changed because time passed.
Any by bumping all dependencies therefore also requiering the latest and
greatest of all dependencies.
It's no longer possible to even guess if the library has been completely
rewritten or if a single bug has been fixed
based on the version number. You can of course argue that this anyways
doesn't work because developers don't care,
but that is first of not generally true, and by allowing for a version
number we would give the individual maintainers
at least the chance to do it properly.

Appart from the communcation aspect, we make library updates
unnecessarily risky because of
the complete frameworks dependency tree getting pulled in (so you have
to pull in 8 updates instead of 1),
which is probably the biggest problem in an enterprise environment.

Cheers,
Christian