Versioning of Frameworks

[Martin Gräßlin]

On Tuesday 05 May 2015 17:30:05 Mario Fux wrote:
> Am Dienstag, 05. Mai 2015, 13.46:16 schrieb Martin Gräßlin:
> 
> Morning
> 
> [snip]
> 
> > > 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. The versioning would be a complete mess: each framework having a 
different version number, some doing bug fix releases, some don't. 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? 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. 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.

> 
> > So far I assumed that you want to change the way how *all* frameworks are
> > released which would imply a significant work load to the maintainers as
> > you just explained yourself.
> 
> As I understood it Christian doesn't want it changed for all maintainers as
> that would almost be rude ;-).
> 
> griits
> Mario
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150505/d27d2b84/attachment-0001.sig>