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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
