Re: Versioning of Frameworks
Hello, On Tuesday 12 May 2015 09:22:12 David Faure wrote: On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote: I think there are two possibilities: * master is the development branch and we have a separate release branch = contributors have it easier because that is perhaps more common, and the people releasing need to know that they shouldn't release off master but off release * master is the release branch and we have a separate development branch Neither of those is how development works in Frameworks. master is the development branch *and* the release branch. Most of the work on any library can be split into small enough chunks that can be committed incrementally, each change being stable and tested. Only very large refactorings (e.g. changing the underlying technology) might sometimes require a work branch, but that is really the exception, smaller refactorings can also be done incrementally. I know I'm late to the party, but I'd just like to express my support on that. It was a deliberate choice to have such a setup in Frameworks, and it's important for the sake of contributions that we don't end up with different rules per framework. Regarding master as both the development branch and the release branch, its aim is to push people to discover unwanted interactions early by creating friction. It'd be senseless used alone. But, if it's combined with reviews and automated tests (ideally TDD but we're still not there yet I'm afraid), then it leads to introducing features in baby steps (because you want to avoid large useless reviews) with a higher quality. It means you can release any time[+]. At least, since we've put that in place in KDE Frameworks, the work keeps coming in with a higher quality than before[++] and the releases are boring. And I mean that in a good way: the release notes are small, it's not a drama anymore to get everyone aligned, no one tries to rush something under the radar to make it to the next release and the generation of the release is mostly automated. It doesn't make for a big PR splash but that's OK in my opinion, especially for KDE Frameworks. Also note that if you get your features by baby steps properly and use either branch by abstraction[*] or feature toggle[**] techniques (those tend to take the form of semi-private/experimental APIs in some of our frameworks) then the whole versioning discussion of this thread is much less relevant as well (it's not as scary anymore to upgrade dependencies of a framework). Regards. [+] http://c2.com/cgi/wiki?ReleaseEasyReleaseOften [++] Even if I bitch and moan regularly about tests and still think it could be better, it be dishonest to not notice there's more peer review and tests than before. [*] http://martinfowler.com/bliki/BranchByAbstraction.html [**] http://martinfowler.com/bliki/FeatureToggle.html -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote: I think there are two possibilities: * master is the development branch and we have a separate release branch = contributors have it easier because that is perhaps more common, and the people releasing need to know that they shouldn't release off master but off release * master is the release branch and we have a separate development branch Neither of those is how development works in Frameworks. master is the development branch *and* the release branch. Most of the work on any library can be split into small enough chunks that can be committed incrementally, each change being stable and tested. Only very large refactorings (e.g. changing the underlying technology) might sometimes require a work branch, but that is really the exception, smaller refactorings can also be done incrementally. You're joining an existing project with existing rules. I made a compromise already on the versioning, can you make a compromise on the git workflow? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Tue, May 12, 2015, at 09:22 AM, David Faure wrote: On Monday 11 May 2015 15:51:20 Christian Mollekopf wrote: I think there are two possibilities: * master is the development branch and we have a separate release branch = contributors have it easier because that is perhaps more common, and the people releasing need to know that they shouldn't release off master but off release * master is the release branch and we have a separate development branch Neither of those is how development works in Frameworks. master is the development branch *and* the release branch. Most of the work on any library can be split into small enough chunks that can be committed incrementally, each change being stable and tested. Only very large refactorings (e.g. changing the underlying technology) might sometimes require a work branch, but that is really the exception, smaller refactorings can also be done incrementally. You're joining an existing project with existing rules. I made a compromise already on the versioning, can you make a compromise on the git workflow? Yes. If the release scripts only release if the version has changed, as discussed, then I'm happy to use that workflow. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Mon, May 11, 2015, at 12:31 AM, David Faure wrote: On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote: Are you volunteering, or just making demands for others to do work for you? I'm volunteering to do the maintenance and release engineering for the libraries that matter to me, and I'm also prepared to work out a proposal on how to i.e. implement that opt-out mechanism. Gah, this discussion is really not helped by the fact that I'm asking *Alex* some questions based on *his* requests, and *you* reply to these questions, while you have *other* requests to start with. Alright, I didn't realize that this was the part you wanted to separate, sorry about the noise. You two are not asking for the same thing, so please don't mix up the two subthreads, it makes no sense for you to answer the questions that I'm asking Alex, who has different demands than you. Alex wants all frameworks to have tightly controlled separate version numbers, which therefore raises the question of who does that work. His request is as user of the frameworks. Your request is as a future maintainer of some frameworks, which is different, and only for the frameworks you'll maintain, which is different. Ok. If you want to increase version numbers at your own pace in your frameworks, then it means you are releasing them at your own pace. Basically it means a bunch of libs which are not part of the monthly KF5 release, but which have their own release schedule. They can be excluded from the release scripts by simply having release: false in their *.yaml file. I'll have to double-check that all scripts honour this (I think I have to fix the version-increasing scripts to check that), but that's doable. Great. It just makes these libs not really frameworks, since they won't be part of the KF 5.11 release, but I guess that's fine, you'll sort out the versioning and messaging around them. From my perspective you could simply release from an always releasable master and would get no additional effort. I don't see how that would work. Say there was only one bugfix in kimap during one month, and no version number increase. What then? I can't just release from master since it would be a release with the same version number as the last release but with different contents. Don't assume you'll always remember to increase the version number every month, that's just wishful thinking. This case *will* happen and I don't want to have to handle it. The way I could see this work is: * I work in a devel branch (and never ever commit to master) * I only ever merge to master for release together with a version bump As a developer merging to master would be part of the release-process, and we could even guarantee that the version is bumped using a push-hook. I don't have to worry about the release cycle, because I simply release (by merging to master) whenever something is supposed to be used from somewhere. An I know all these updates get picked up with the next release cycle of frameworks. If the versioning is independent, then the release schedule is independent, by definition. But that doesn't necessarily mean they can't be part of the same distribution mechanism. If you simply take a snapshot of all frameworks every month, then it shouldn't matter if they changed or not. If no change has been made, the version would simply stay the same. For packagers it remains trivial to pick up the latest released set because they know when and where to get that set, and thus don't have to deal with each library individually. So basically you'd have libs which are released separately, whether we call them frameworks or not becomes purely a marketing question. Well there is still a very important message given by being part of frameworks: * We commit to binary compatibility * We commit to the licensing as defined by frameworks * We commit to stick to the tiers system This is IMO very valuable for potential users of the library, because they can more or less blindly pick a framework, knowing that they get these commitments. For all I know frameworks is supposed to be the pool collecting all sorts of quality Qt libraries, and therefore the goto place for people requiring something that is not in Qt already. I think this is very valuable and not purely marketing (although that is certainly part of it). When it comes to the version of the *dependencies* of your libs, they don't have to use the auto-increased KF5_DEP_VERSION. That's easy to opt out from. We'll just come back shouting when someone forgets to increase it correctly in your frameworks or some code that depends on them, but for now you have the benefit of the doubt :-) Thanks =) Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Monday 11 May 2015 11:57:02 Christian Mollekopf wrote: But that doesn't necessarily mean they can't be part of the same distribution mechanism. If you simply take a snapshot of all frameworks every month, then it shouldn't matter if they changed or not. If no change has been made, the version would simply stay the same. Well, someone can fix a bug in master, but yeah, that means excluding a manual-versioning framework if its version number is the same as last time. The yaml file would get a new field versioning which can be auto or manual (defaulting to auto), and the version-updating scripts would skip frameworks with versioning: manual, while the release scripts would grab these frameworks (provided they have release: true of course), with additional logic to skip them if the version is the same as last time. This still creates a mess in the sense that the 'KDE Frameworks 5.11' release might contain KImap 5.3, or no new version of KImap at all. So I still don't like it, it makes things harder for people's understanding of versioning (users, packagers, developers etc.). But I can respect the maintainer's (=your) decision to make it work like that, any version messup being on your shoulders. If people complain too much about the inconsistent versioning, we can always revisit, I'll have more arguments then :) I'm not sure about the branch merging btw. It will not make it easy to generate the list of changes since last time, which is supposed to be done by a git log old..new script. If there's a big merge commit instead of 15 commits then we don't get a changelog. Unless you write the full changelog in the merge commit. Alternatively, you can just work in master. This alos avoids the usual issue of I have it all redone/fixed in my branch, no point in you fixing bugs in the code you're currently using from master, which basically kills any external contribution to one's code. IOW manual versioning doesn't require that all changes should happen in a work branch. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Mon, May 11, 2015, at 02:42 PM, David Faure wrote: On Monday 11 May 2015 11:57:02 Christian Mollekopf wrote: But that doesn't necessarily mean they can't be part of the same distribution mechanism. If you simply take a snapshot of all frameworks every month, then it shouldn't matter if they changed or not. If no change has been made, the version would simply stay the same. Well, someone can fix a bug in master, but yeah, that means excluding a manual-versioning framework if its version number is the same as last time. The yaml file would get a new field versioning which can be auto or manual (defaulting to auto), and the version-updating scripts would skip frameworks with versioning: manual, while the release scripts would grab these frameworks (provided they have release: true of course), with additional logic to skip them if the version is the same as last time. That sounds perfect to me =) This still creates a mess in the sense that the 'KDE Frameworks 5.11' release might contain KImap 5.3, or no new version of KImap at all. So I still don't like it, it makes things harder for people's understanding of versioning (users, packagers, developers etc.). But I can respect the maintainer's (=your) decision to make it work like that, any version messup being on your shoulders. If people complain too much about the inconsistent versioning, we can always revisit, I'll have more arguments then :) Works for me. We seem to disagree on the versioning topic, so thanks a lot for still working together with me on this =) I'm not sure about the branch merging btw. It will not make it easy to generate the list of changes since last time, which is supposed to be done by a git log old..new script. If there's a big merge commit instead of 15 commits then we don't get a changelog. I would still merge all the commits, just always in a batch that results in a new version. So the changelog script should continue to work as it does now. Unless you write the full changelog in the merge commit. Alternatively, you can just work in master. This alos avoids the usual issue of I have it all redone/fixed in my branch, no point in you fixing bugs in the code you're currently using from master, which basically kills any external contribution to one's code. I think there are two possibilities: * master is the development branch and we have a separate release branch = contributors have it easier because that is perhaps more common, and the people releasing need to know that they shouldn't release off master but off release * master is the release branch and we have a separate development branch what's what doesn't matter to me but we should decide on one solution, so if everything else uses master for development, maybe a release branch would do? IOW manual versioning doesn't require that all changes should happen in a work branch. True. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Mon, May 11, 2015, at 12:05 AM, Albert Astals Cid wrote: El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va escriure: On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va escriure: On Sunday, May 10, 2015 15:39:02 David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. it's not just him. It's me (at work) too. Maybe many developers which use Qt at work (with an commercial license). There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). This indeed requires that maintainers carefully maintain which versions of their dependencies are needed (sometimes not requiring the newest version is also a good thing). Honestly it is your job as creator of a product based on this libraries to decide if to upate to the next version with what it entails or to cherry-pick the bugfix into your code (as you do with Qt). What you're dreaming is a library that does what you want and has no dependencies, because for you the problem is not that updating kfoo may depends on kcoreaddons and kwidgetaddons, it is that has any dependencies at all, what if the same release that fixes the bug you need adds a new feature that introduces a dependency in liblava? You have the same problem. There's always the possibility of such problems, but they can be greatly reduced. Of course I understand that you'd prefer that we did this stabilization work instead of you, but you have to understand there's simply not the manpower to do this. I'd like to point out that all that is wanted that I'm allowed to do this for the libraries where I do the work, I don't exactly get what is do this, is it only not autoupdate the depencency versions to the other frameworks? Is it also not autoincreasing the version number? Is it something else? It's not autoincreasing the version number, and not autobumping the dependencies. As a maintainer I'd bump the version and dependencies myself, and the latest stable version could be released at any time from i.e. an always releasable master. So there would IMO be no additional overhead for other people. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sun, May 10, 2015, at 11:13 PM, David Faure wrote: On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote: There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Well, I wish you would see KF5 as a natural extension of Qt, therefore a system library too, if you want to call it that. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). Then just grab the bugfix, or adjust the required-version if you see it doesn't need functionality from a newer version. This indeed requires that maintainers carefully maintain which versions of their dependencies are needed You realize that many frameworks don't have a maintainer, right? At least 17 have officially none, others might have an inactive one. It's perfectly fine to continue doing what you do where noone is offering to do the work. I'd like to opt out of the version bumping practice for where I can do the work. Are you volunteering, or just making demands for others to do work for you? I'm volunteering to do the maintenance and release engineering for the libraries that matter to me, and I'm also prepared to work out a proposal on how to i.e. implement that opt-out mechanism. If such a change would make your job somehow more difficult I'd definitely also work on that if you tell me what breaks or just what you're release work currently is so I can figure it out myself. From my perspective you could simply release from an always releasable master and would get no additional effort. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va escriure: On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. I completely understand that. I'm searching for a solution that works for everyone, and I'm pointing out that the current situation does not work for me (as a maintainer of kimap that should become a framework, as a KDE PIM developer and as kolab developer). I only wanted to elaborate on why I can deal with the Qt situation, but can't really with the one in frameworks. I just want to point the obvious solution of you don't need to make kimap a framework, you can just release it yourself and problem fixed (not sure if anyone had before, it's a long thread :D) So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). I'm trying to point out that this solution does not work for the scenario I want to use certain (soon to be) frameworks, which is deployed on a server in an enterprise environment. In these scenarios I can't just tell to run the proverbial yum update to pull in as many packages as I like. Either I manage to keep changes to a justifiable minimum that we can be tested sufficiently, or I have to implement a workaround. And implementing workarounds to use the real fixes a year later once we actually get to upgrade all systems to the required frameworks version is not a sustainable solution. You can implement stuff in KF5 and use it the month that follows in the layers above. In an enterprise environment I simply can't. This works very well for the developer on his bleeding edge machine, but in other cases just doesn't. In an enterprise environment, you control everything, just cherry-pick the fixes you need, since we're assuming here you need exactly the bugfixes you want (since you know which versions to update and where, etc) This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. There are numerous reasons for me to advocate individual version numbers per library that are controlled by the maintainer, but I don't see the discussions as orthogonal: * I need the version number as a tool as maintainer to do some release engineering. * Bumping version numbers and dependencies periodically doesn't work for the enterprise usecase (due to random changes getting pulled in for an otherwise trivial update). That's nothing to do with bumping version numbers, and everything to do with the lack of a stable version, again as an enterprise, it's your task to productize the library if the library doesn't do everything you need. * By removing the version number we remove a valuable communication tool from the individual libraries. I appreciate all the work you're doing, and I'm certainly not trying to make your life or anyone elses harder, but these are actual problems I'm facing that I need to solve somehow, and that I think are solvable. But it would help to get some more input on what the actual problems on your end are other than some references to version hell. If we can solve the problems I'm also perfectly willing to do the work that is necessary. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va escriure: On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va escriure: On Sunday, May 10, 2015 15:39:02 David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. it's not just him. It's me (at work) too. Maybe many developers which use Qt at work (with an commercial license). There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). This indeed requires that maintainers carefully maintain which versions of their dependencies are needed (sometimes not requiring the newest version is also a good thing). Honestly it is your job as creator of a product based on this libraries to decide if to upate to the next version with what it entails or to cherry-pick the bugfix into your code (as you do with Qt). What you're dreaming is a library that does what you want and has no dependencies, because for you the problem is not that updating kfoo may depends on kcoreaddons and kwidgetaddons, it is that has any dependencies at all, what if the same release that fixes the bug you need adds a new feature that introduces a dependency in liblava? You have the same problem. There's always the possibility of such problems, but they can be greatly reduced. Of course I understand that you'd prefer that we did this stabilization work instead of you, but you have to understand there's simply not the manpower to do this. I'd like to point out that all that is wanted that I'm allowed to do this for the libraries where I do the work, I don't exactly get what is do this, is it only not autoupdate the depencency versions to the other frameworks? Is it also not autoincreasing the version number? Is it something else? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday, May 10, 2015 15:39:02 David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. it's not just him. It's me (at work) too. Maybe many developers which use Qt at work (with an commercial license). There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). This indeed requires that maintainers carefully maintain which versions of their dependencies are needed (sometimes not requiring the newest version is also a good thing). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote: There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Well, I wish you would see KF5 as a natural extension of Qt, therefore a system library too, if you want to call it that. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). Then just grab the bugfix, or adjust the required-version if you see it doesn't need functionality from a newer version. This indeed requires that maintainers carefully maintain which versions of their dependencies are needed You realize that many frameworks don't have a maintainer, right? At least 17 have officially none, others might have an inactive one. Are you volunteering, or just making demands for others to do work for you? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote: Are you volunteering, or just making demands for others to do work for you? I'm volunteering to do the maintenance and release engineering for the libraries that matter to me, and I'm also prepared to work out a proposal on how to i.e. implement that opt-out mechanism. Gah, this discussion is really not helped by the fact that I'm asking *Alex* some questions based on *his* requests, and *you* reply to these questions, while you have *other* requests to start with. You two are not asking for the same thing, so please don't mix up the two subthreads, it makes no sense for you to answer the questions that I'm asking Alex, who has different demands than you. Alex wants all frameworks to have tightly controlled separate version numbers, which therefore raises the question of who does that work. His request is as user of the frameworks. Your request is as a future maintainer of some frameworks, which is different, and only for the frameworks you'll maintain, which is different. If you want to increase version numbers at your own pace in your frameworks, then it means you are releasing them at your own pace. Basically it means a bunch of libs which are not part of the monthly KF5 release, but which have their own release schedule. They can be excluded from the release scripts by simply having release: false in their *.yaml file. I'll have to double-check that all scripts honour this (I think I have to fix the version-increasing scripts to check that), but that's doable. It just makes these libs not really frameworks, since they won't be part of the KF 5.11 release, but I guess that's fine, you'll sort out the versioning and messaging around them. From my perspective you could simply release from an always releasable master and would get no additional effort. I don't see how that would work. Say there was only one bugfix in kimap during one month, and no version number increase. What then? I can't just release from master since it would be a release with the same version number as the last release but with different contents. Don't assume you'll always remember to increase the version number every month, that's just wishful thinking. This case *will* happen and I don't want to have to handle it. If the versioning is independent, then the release schedule is independent, by definition. So basically you'd have libs which are released separately, whether we call them frameworks or not becomes purely a marketing question. When it comes to the version of the *dependencies* of your libs, they don't have to use the auto-increased KF5_DEP_VERSION. That's easy to opt out from. We'll just come back shouting when someone forgets to increase it correctly in your frameworks or some code that depends on them, but for now you have the benefit of the doubt :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. I completely understand that. I'm searching for a solution that works for everyone, and I'm pointing out that the current situation does not work for me (as a maintainer of kimap that should become a framework, as a KDE PIM developer and as kolab developer). I only wanted to elaborate on why I can deal with the Qt situation, but can't really with the one in frameworks. So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). I'm trying to point out that this solution does not work for the scenario I want to use certain (soon to be) frameworks, which is deployed on a server in an enterprise environment. In these scenarios I can't just tell to run the proverbial yum update to pull in as many packages as I like. Either I manage to keep changes to a justifiable minimum that we can be tested sufficiently, or I have to implement a workaround. And implementing workarounds to use the real fixes a year later once we actually get to upgrade all systems to the required frameworks version is not a sustainable solution. You can implement stuff in KF5 and use it the month that follows in the layers above. In an enterprise environment I simply can't. This works very well for the developer on his bleeding edge machine, but in other cases just doesn't. This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. There are numerous reasons for me to advocate individual version numbers per library that are controlled by the maintainer, but I don't see the discussions as orthogonal: * I need the version number as a tool as maintainer to do some release engineering. * Bumping version numbers and dependencies periodically doesn't work for the enterprise usecase (due to random changes getting pulled in for an otherwise trivial update). * By removing the version number we remove a valuable communication tool from the individual libraries. I appreciate all the work you're doing, and I'm certainly not trying to make your life or anyone elses harder, but these are actual problems I'm facing that I need to solve somehow, and that I think are solvable. But it would help to get some more input on what the actual problems on your end are other than some references to version hell. If we can solve the problems I'm also perfectly willing to do the work that is necessary. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sat, May 9, 2015, at 01:27 PM, David Faure wrote: On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote: we pretend it's all independent libraries but still they all depend on the latest version of all other libs. It's a question of the definition of independent. E.g. KCoreAddons and Solid are independent because you can use either one without being forced to use the other. The fact that they are released together doesn't change that. Indeed, the split up is in any case a valuable change from what it used to be. KCoreAddons and KIO are partially independent because KIO depends on KCoreAddons, but still there is a huge improvement there compared to the kdelibs4 situation where such inter-library-dependencies were far too numerous so it was basically all-or-nothing. Having split two such libraries still helps tremendously, since one can use KCoreAddons without using KIO. The fact that KIO-5.10 requires KCoreAddons-5.10 is IMHO no different from the fact that QtGui-5.6 requires QtCore-5.6. Are you saying that Qt didn't go all the way or didn't split properly because of the fact that QtGui-5.6 requires QtCore-5.6? (same thing with other Qt libs from other modules than qtbase, this isn't limited to qtbase) I do think the same problem applies to Qt, and yes as long as they have the same version for all libraries they are not completely independent. It may be less of a problem for Qt though than it is for frameworks IMO. I still don't understand why this is fine for Qt and not for KDE Frameworks. Two reasons why Qt can get away with treating it as a single library (which it IMO largely does): * Qt libraries tend to be less volatile. I can implement most functionality I require today on top of Qt 4.6. That means I simply implement workarounds for what I don't have available on an older system, and I typically don't even consider changing something in Qt (which is a shame because it keeps me from improving Qt). We therefore simply avoid updating Qt as far as possible, because if we have to we indeed also have this giant blob to update. * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. Qt does include a *lot* of stuff though, which I think Qt would also benefit from truly splitting up libraries. Frameworks for me is an umbrella for various libraries, and not a single library. If it were a single library it would be an everything and the kitchen sink library, which I really don't think is something we should be aiming for. So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. So as a summary, it's only fine for Qt because I never ever have to touch Qt, which is not a good thing either. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. Qt does include a *lot* of stuff though, which I think Qt would also benefit from truly splitting up libraries. Qt *is* splitted. It's just that the splitted libs are released together. Frameworks for me is an umbrella for various libraries, and not a single library. If it were a single library it would be an everything and the kitchen sink library, which I really don't think is something we should be aiming for. One could say the same about Qt, but this argument won't lead us anywhere so let's skip that. So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). You can implement stuff in KF5 and use it the month that follows in the layers above. This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday, 10 May 2015 15:39:02 CEST, David Faure wrote: Qt *is* splitted. It's just that the splitted libs are released together. The splitting of Qt is not full and complete, however. Modules tend to use each other's internal APIs, and that's the biggest reason for not supporting random mixing of different versions of Qt modules. Reducing the supported space of all possible combinations is another reason for sure, so I understand your point about doing the same in KF -- just explaining that in case of Qt5, there are other reasons as well. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). You can implement stuff in KF5 and use it the month that follows in the layers above. This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. I think that Christian is saying that he can't really just use a new version of a particular framework because that new version brings along a lot of unrelated changes as well. For some reason (extra testing is required, we want stability) he doesn't want to follow that path. I think that it's a useful feedback from a user's point of view. I don't have an answer on how to fix this without introducing extra work to KF5 maintainers, though. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote: we pretend it's all independent libraries but still they all depend on the latest version of all other libs. It's a question of the definition of independent. E.g. KCoreAddons and Solid are independent because you can use either one without being forced to use the other. The fact that they are released together doesn't change that. KCoreAddons and KIO are partially independent because KIO depends on KCoreAddons, but still there is a huge improvement there compared to the kdelibs4 situation where such inter-library-dependencies were far too numerous so it was basically all-or-nothing. Having split two such libraries still helps tremendously, since one can use KCoreAddons without using KIO. The fact that KIO-5.10 requires KCoreAddons-5.10 is IMHO no different from the fact that QtGui-5.6 requires QtCore-5.6. Are you saying that Qt didn't go all the way or didn't split properly because of the fact that QtGui-5.6 requires QtCore-5.6? (same thing with other Qt libs from other modules than qtbase, this isn't limited to qtbase) I still don't understand why this is fine for Qt and not for KDE Frameworks. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Friday, May 08, 2015 10:32:22 Christian Mollekopf wrote: On Tue, May 5, 2015, at 05:38 PM, Martin Gräßlin wrote: ... 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. So +1 ... ... 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. Same here, +1 Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Tuesday, May 05, 2015 11:33:03 Christian Mollekopf wrote: 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. Exactly. At work we depend on a small number of additional libraries (BSD- licensed ones). We update them only if they fix something we really need. When doing that, we check what else has changed there. If a bugfix in one of those libs would require us to update 5 other libs too (because they happened to increase their version number), that would be a major problem for us, because it would mean a lot of unnecessary checking what has changed. * 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. +1. That's what we (KDE) somehow decided for when saying we'll split it all into frameworks, but then didn't go the wole way, but we pretend it's all independent libraries but still they all depend on the latest version of all other libs. Nobody wanted to agree to this when I raised that issue two or three years ago: if we do the split properly, we get dependency hell, that's simply the cost of it. But it has its good sides too, as you point out. ... 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. I'm afraid here we have the problem, many libraries are missing these maintainers. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org
Re: Versioning of Frameworks
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),
Re: Versioning of Frameworks
On Wed, May 6, 2015, at 01:42 PM, Jan Kundrát wrote: Hi Christian, Hi Jan, I think that the stuff you're looking for (reducing version churn) can also be provided by having stable branches for selected parts of KF5. IMHO this can be quite an elegant solution given the usual cat-herding problem of FLOSS where people just do what they want to do. Those who value the benefits of having bugfix-only releases and those willing to put their time into this could well branch from a random KF5 release and keep backporting bugfixes. I can give you CI coverage pretty easily for this. Would this solve this problem for you, and would you volunteer to become a maintainer for this? Has this been discussed before, or is there some reason against doing this? It's unfortunately only part of the solution. Stable branches are indeed a useful tool to backport fixes, as long as no new features are required, but they become increasingly expensive to maintain (the more master diverges from that branch). So while they're excellent to backport a fix or two, they are not the correct solution if new features are required (or any large patch for that matter). So on a server where we need use kcalcore through libkolab, as long as we only need some bugfixes we simply backport that patch to the relevant branch (say 5.4, bump the patch version, say 5.4.3 and update just that). That way we can confidently update knowing precisely what changed. If we need a new feature, and that's available only in 5.6, we'd have to do some more testing, but still, by the nature of these libraries dependencies need very rarely to be bumped (the functionality provided is easily implemented on libraries 5 years old), so again, we know exactly what changed by simply looking at one library. With current frameworks we'd end up updating from 5.6 to 5.13, and then pull in changes from all dependencies within frameworks, unless we essentially fork all frameworks and drop the dependencies again, which frankly is a waste of everyone's time and precisely what I hoped to get away from with frameworks. So with the way frameworks currently deals with versions it becomes prohibitively expensive and/or risky to use it in an enterprise environment, where you sometimes just cannot afford stuff to break, which is why I need a solution for this. Thanks for leading this discussion into a more solution oriented direction =) Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
Hi Christian, I think that the stuff you're looking for (reducing version churn) can also be provided by having stable branches for selected parts of KF5. IMHO this can be quite an elegant solution given the usual cat-herding problem of FLOSS where people just do what they want to do. Those who value the benefits of having bugfix-only releases and those willing to put their time into this could well branch from a random KF5 release and keep backporting bugfixes. I can give you CI coverage pretty easily for this. Would this solve this problem for you, and would you volunteer to become a maintainer for this? Has this been discussed before, or is there some reason against doing this? Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote: On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: 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. Currently release management in KDE means that the release management does the increase of version numbers with the help of automated tools. This means that I as a maintainer of multiple components don't have to follow the release cycles of all the different components. I normally don't know when * frameworks tag * kde-workspace tag * applications tag I think it's very good that you don't have to worry about the release cycle as a maintainer, and I'd like to keep it that way. I don't see how. See my questions further down. If you move the responsibility to increase version numbers to the maintainers, I fear that we would have huge breakage. Just the fact that with the one-month release cycle of frameworks a maintainer is no longer allowed to become ill for more than three weeks or go on vacations for such a long time. No, it just means that a frameworks release can contain the same version repeatedly if nothing has changed. and how exactly is the version going to change if there have been commits? Currently this is done without the maintainer having to care about it. With what you suggest someone (being maintainer or release manager) has to verify otherwise it's possible that a commit goes into a release without a change of version number. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
On Tuesday 05 May 2015 13:40:24 Christian Mollekopf wrote: On Tue, May 5, 2015, at 01:31 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote: On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: 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. Currently release management in KDE means that the release management does the increase of version numbers with the help of automated tools. This means that I as a maintainer of multiple components don't have to follow the release cycles of all the different components. I normally don't know when * frameworks tag * kde-workspace tag * applications tag I think it's very good that you don't have to worry about the release cycle as a maintainer, and I'd like to keep it that way. I don't see how. See my questions further down. If you move the responsibility to increase version numbers to the maintainers, I fear that we would have huge breakage. Just the fact that with the one-month release cycle of frameworks a maintainer is no longer allowed to become ill for more than three weeks or go on vacations for such a long time. No, it just means that a frameworks release can contain the same version repeatedly if nothing has changed. and how exactly is the version going to change if there have been commits? As the maintainer of the library I'd preparing the next release in a branch. If it is a bugfix release (e.g from 1.6.1 to 1.6.2), I'd merge that new version into master so it would be released with the next frameworks release. If would, in parallel to doing the bugfix releases for 1.6, prepare 1.7.0. Once the 1.7.0 has all planned features in and is sufficiently stable, I'd merge the 1.7.0 release into master so it gets released. Currently this is done without the maintainer having to care about it. With what you suggest someone (being maintainer or release manager) has to verify otherwise it's possible that a commit goes into a release without a change of version number. 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. 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. signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
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? 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@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
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@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Tue, May 5, 2015, at 01:31 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 13:20:25 Christian Mollekopf wrote: On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: 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. Currently release management in KDE means that the release management does the increase of version numbers with the help of automated tools. This means that I as a maintainer of multiple components don't have to follow the release cycles of all the different components. I normally don't know when * frameworks tag * kde-workspace tag * applications tag I think it's very good that you don't have to worry about the release cycle as a maintainer, and I'd like to keep it that way. I don't see how. See my questions further down. If you move the responsibility to increase version numbers to the maintainers, I fear that we would have huge breakage. Just the fact that with the one-month release cycle of frameworks a maintainer is no longer allowed to become ill for more than three weeks or go on vacations for such a long time. No, it just means that a frameworks release can contain the same version repeatedly if nothing has changed. and how exactly is the version going to change if there have been commits? As the maintainer of the library I'd preparing the next release in a branch. If it is a bugfix release (e.g from 1.6.1 to 1.6.2), I'd merge that new version into master so it would be released with the next frameworks release. If would, in parallel to doing the bugfix releases for 1.6, prepare 1.7.0. Once the 1.7.0 has all planned features in and is sufficiently stable, I'd merge the 1.7.0 release into master so it gets released. Currently this is done without the maintainer having to care about it. With what you suggest someone (being maintainer or release manager) has to verify otherwise it's possible that a commit goes into a release without a change of version number. 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. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
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. Hi, as ktexteditor framework and kate maintainer, I think, too, that if we start to go that way, we will end in the version hell. ATM it is easy to track: Ok, I have a bug for KTextEditor 5.9, that means all frameworks used are at least 5.9, too. Its already hard enough to track for bugs on the application side: Ok, I have Kate from Applications 15.04 and it uses KF 5.9 ;=) That was much easier in the I have KDE 4.1.2 times, where all things were more or less fixed in their version and one number is all you need ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
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
Re: Versioning of Frameworks
On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote: On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: You don't have to maintain any other combinations that what you already do. Just because the cmake versions aren't automatically bumped doesn't mean you suddenly have to test every conceivable combination of versions. How can the developer write in KIO's CMakeLists.txt this depends on KXmlGui 5.5 and KCoreAddons 5.2 without testing that it actually works with these versions? Because he tested that when he originally added that dependency, and never changed anything related to that. Or the other way around -- if it is at one point indeed working with these versions, what will happen is that someone will use a new feature from an underlying framework at some point, and forget to upgrade the required version. This will happen many times per month, not just once a year, I know this for sure. Yes, if somebody introduces a bug we have a bug. If I as a maintainer of a library decide keep dependencies low it's my responsibility to keep that working. Personally I'd do that using CI, by building additionally to a system with the latest version, in a system that has only the minimum dependencies installed. It's additional work, but it IMO yields a higher quality product, and it's what I'll have to do if I want that library to be used in an enterprise environment. See the number of times where someone commits Qt-5.4-only code right now in frameworks that are supposed to work with Qt 5.2, but they don't realize when writing QSignalSpy(obj, Class::member) that this syntax wasn't available in Qt 5.2. It's already a fight to get this right with the *one* Qt version number, I can't even imagine how tricky this would become with 62 * 5 = 310 version numbers to keep right (62 frameworks each depending on an average of 5 other frameworks - I made up that number, feel free to calculate it more precisely). I know it can be tricky, happens to me as well. Simply ignoring the problem by always bumping all requirements doesn't result in a higher quality product though. The complexity is not as high as you make it sound, because the maintainer of the library is the one that also maintains it's version number (or should be IMO), if there is a lack of manpower for some libraries to do that they can continue to do what they've been doing. Anyhow, there is little point in arguing for ever about this. As long as I'm doing the Frameworks releases, they will have the same version numbers and they will require the same version number from their dependent frameworks. Sorry to put it so bluntly, but there is no other solution that is actually manageable. Releasing framework is already not a fun task, I will gladly give it over to someone else if they think they can do a better job, but OTOH I think the current release process works quite well (changelog aside), so I would not advocate this (changing it by having someone else do it differently). That's unfortunate. I think this is a problem and I do hope we'll find a solution that works for everyone. I completely understand that you don't want this already complex task to be any more complex, but IMO it wouldn't have to be. Thanks for the detailed responses in any case. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote: On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: You don't have to maintain any other combinations that what you already do. Just because the cmake versions aren't automatically bumped doesn't mean you suddenly have to test every conceivable combination of versions. How can the developer write in KIO's CMakeLists.txt this depends on KXmlGui 5.5 and KCoreAddons 5.2 without testing that it actually works with these versions? Because he tested that when he originally added that dependency, and never changed anything related to that. That's wishful thinking, isn't it? I already gave you examples on how we regularly forget to increase the required versions in KWin . Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: 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. Currently release management in KDE means that the release management does the increase of version numbers with the help of automated tools. This means that I as a maintainer of multiple components don't have to follow the release cycles of all the different components. I normally don't know when * frameworks tag * kde-workspace tag * applications tag If you move the responsibility to increase version numbers to the maintainers, I fear that we would have huge breakage. Just the fact that with the one-month release cycle of frameworks a maintainer is no longer allowed to become ill for more than three weeks or go on vacations for such a long time. If such a responsibility would be moved to the maintainers I would immediately step down as a frameworks maintainer, because knowing myself I would more often forget about it than not. Also it would add an additional workload on my shoulders, which I don't have time for. Automated tools are quite awesome to increase version numbers. Thank you very much to not require me to do it manually! Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Tue, May 5, 2015, at 12:11 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote: On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: You don't have to maintain any other combinations that what you already do. Just because the cmake versions aren't automatically bumped doesn't mean you suddenly have to test every conceivable combination of versions. How can the developer write in KIO's CMakeLists.txt this depends on KXmlGui 5.5 and KCoreAddons 5.2 without testing that it actually works with these versions? Because he tested that when he originally added that dependency, and never changed anything related to that. That's wishful thinking, isn't it? No it isn't. I'm doing that for libkolabxml and libkolab since quite a while now. Obviously I break stuff every now and then for i.e. CentOS6, and a lack of the necessary CI infrastructure could make it difficult at times to keep everything working. However, it's a requirement for kolab to keep this working, so I do what is necessary to achieve that. Now that we have better CI infrastructure it becomes much easier to ensure I don't break anything, the rest is a simple matter of fixing what I break. I already gave you examples on how we regularly forget to increase the required versions in KWin . Which doesn't mean everyone does, or that simply ignoring the problem solves it. I'm not trying to force everyone to care about that aspect, I'm trying to enable those that do (me). Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Tue, May 5, 2015, at 12:09 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 11:33:03 Christian Mollekopf wrote: 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. Currently release management in KDE means that the release management does the increase of version numbers with the help of automated tools. This means that I as a maintainer of multiple components don't have to follow the release cycles of all the different components. I normally don't know when * frameworks tag * kde-workspace tag * applications tag I think it's very good that you don't have to worry about the release cycle as a maintainer, and I'd like to keep it that way. If you move the responsibility to increase version numbers to the maintainers, I fear that we would have huge breakage. Just the fact that with the one-month release cycle of frameworks a maintainer is no longer allowed to become ill for more than three weeks or go on vacations for such a long time. No, it just means that a frameworks release can contain the same version repeatedly if nothing has changed. If such a responsibility would be moved to the maintainers I would immediately step down as a frameworks maintainer, because knowing myself I would more often forget about it than not. Also it would add an additional workload on my shoulders, which I don't have time for. Automated tools are quite awesome to increase version numbers. Thank you very much to not require me to do it manually! Which is why I'm suggesting to make this optional. I don't agree that bumping a version number is any significant additional work, but if you feel it is then it's up to you to make that decision. I'd like a way to opt-out of that practice, where I'm doing the work. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
On Tuesday 05 May 2015 13:14:08 Christian Mollekopf wrote: On Tue, May 5, 2015, at 12:11 PM, Martin Gräßlin wrote: On Tuesday 05 May 2015 11:45:19 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 09:45 PM, David Faure wrote: On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: You don't have to maintain any other combinations that what you already do. Just because the cmake versions aren't automatically bumped doesn't mean you suddenly have to test every conceivable combination of versions. How can the developer write in KIO's CMakeLists.txt this depends on KXmlGui 5.5 and KCoreAddons 5.2 without testing that it actually works with these versions? Because he tested that when he originally added that dependency, and never changed anything related to that. That's wishful thinking, isn't it? No it isn't. I'm doing that for libkolabxml and libkolab since quite a while now. Obviously I break stuff every now and then for i.e. CentOS6, and a lack of the necessary CI infrastructure could make it difficult at times to keep everything working. However, it's a requirement for kolab to keep this working, so I do what is necessary to achieve that. Now that we have better CI infrastructure it becomes much easier to ensure I don't break anything, the rest is a simple matter of fixing what I break. I already gave you examples on how we regularly forget to increase the required versions in KWin . Which doesn't mean everyone does, or that simply ignoring the problem solves it. I'm not trying to force everyone to care about that aspect, I'm trying to enable those that do (me). erm, maybe I'm misunderstanding something. But you want to change policies of frameworks release progress. So that sounds to me like you want to force each of the maintainers to care about it. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
El Dijous, 30 d'abril de 2015, a les 10:35:59, Kevin Funk va escriure: On Wednesday, April 29, 2015 21:43:20 David Faure wrote: On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote: Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a too recent version of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick dirty way) If this contributor was trying to fix a bug in a Qt module, he would experience the exact same thing. QtAnything 5.5 cannot be compiled with QtBase 5.2. I'm fairly sure you can; let's say build QtWebChannel 5.6 (dev) against QtBase 5.4.1. In fact, I just tried again and it worked just fine. QMake did not complain. One example doesn't mean it works for all ;) Try compiling qtdeclarative 5.5 against qtbase 5.4 and see it explode (qmake doesn't complain either, make will). Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
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 **
Re: Versioning of Frameworks
Hey, Or the other way around -- if it is at one point indeed working with these versions, what will happen is that someone will use a new feature from an underlying framework at some point, and forget to upgrade the required version. This will happen many times per month, not just once a year, I know this for sure. See the number of times where someone commits Qt-5.4-only code right now in frameworks that are supposed to work with Qt 5.2, but they don't realize when writing QSignalSpy(obj, Class::member) that this syntax wasn't available in Qt 5.2. It's already a fight to get this right with the *one* Qt version number, I can't even imagine how tricky this would become with 62 * 5 = 310 version numbers to keep right (62 frameworks each depending on an average of 5 other frameworks - I made up that number, feel free to calculate it more precisely). The minimal build dependency can also be tested via CI. For example on debian we create symbol files, with ther version, where they were added. With these debian sets the minimal dependency. And frameworks have BIC guarantee, so the symbols should be tested via CI anyhow, to prove that guarantee. I know that, also if the symbols haven't changed, important bugs can be fixed in newer version, so newer version are needed/recommended. But a minimal build dependecy never says, that it is not recommended to use never ones :) 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. me as packagers: no, still download the nestest hottest shit and package this. Via symbolfiles I can set the mininimal dependency. Put the packages at a repo and users will get the new ones. me as developers: no, if I work for example at kdepim I need many frameworks, so I compile them once. Afterwards i only compile newer frameworks, if i need to :) This either happens, because a featuers need a new frameworks (fails compiling) or cmake says so. If i have to update one framework i get master. Regards, sandro ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Thursday 30 April 2015 10:35:59 Kevin Funk wrote: QtAnything 5.5 cannot be compiled with QtBase 5.2. I'm fairly sure you can; let's say build QtWebChannel 5.6 (dev) against QtBase 5.4.1. In fact, I just tried again and it worked just fine. QMake did not complain. I would say Qt does it worse: the buildsystem won't complain, but very often you end up with a compilation error, due to an enum value or method not found in qtbase. So you only discover this after 30 minutes of compiling. Being told before hand by the buildsystem would be an improvement... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Wednesday, April 29, 2015 21:43:20 David Faure wrote: On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote: Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a too recent version of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick dirty way) If this contributor was trying to fix a bug in a Qt module, he would experience the exact same thing. QtAnything 5.5 cannot be compiled with QtBase 5.2. I'm fairly sure you can; let's say build QtWebChannel 5.6 (dev) against QtBase 5.4.1. In fact, I just tried again and it worked just fine. QMake did not complain. Sometimes it's interesting to keep the version of the dependencies and just play around with the version of the module you're interested into, in order to evaluate changes in behavior of your module. By that, you can rule out modifications in your *dependencies* did cause these changes in behavior in your module. I also think this somehow defeats the purpose of the splitting we've done when you still have to make sure versions of the individual frameworks have to be identical... So do you also think that Qt failed with the module split ? I disagree. The point (both for Qt and for Frameworks) is that any app can decide to use only what they need. Having to use up-to-date enough versions of the dependent modules does not defeat that purpose. I can clearly see that lifting the restriction of having up-to-date versions of your dependencies creates a version zoo as you say. It's untestable b/c of the potential combinations and clearly doesn't make the maintainer's job easier. However, I think it could be helpful to be able to build master branch of $MODULE against a stable version of its dependencies for *development purposes*, which currently isn't possible. That doesn't mean we should encourage distros to ship a mix of KF5 package versions, obviously. They should continue to ship KF5 with identical versions for each of the frameworks. @David: Didn't stress that enough, but huge thanks for taking care of the KF5 releases! Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Wednesday, April 29, 2015 21:45:14 David Faure wrote: but they don't realize when writing QSignalSpy(obj, Class::member) that this syntax wasn't available in Qt 5.2. I wasn't aware that this has been added, very useful. Thanks! :-) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Thursday 30 April 2015 10:35:59 Kevin Funk wrote: However, I think it could be helpful to be able to build master branch of $MODULE against a stable version of its dependencies for *development purposes*, which currently isn't possible. OK, that is easily fixable. I can raise the version number of the frameworks at the beginning of the month (just after the previous release), and raise the version number of their required dependencies (which I already do in a second step anyway, to keep the CI happy), at the end of the month, just before the release. This will make it possible to hack on a 5.10 framework using 5.9 dependencies, with of course the small risk that it might not compile if it already uses some 5.10 API from a dependency. This will still require the very latest release though, no hacking 5.10 with 5.5 installed. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote: On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf chrig...@fastmail.fm wrote: Hi Christian, I understand your needs, I've seen similar complaints before. Letting frameworks depend on different versions could make sense, but I also fear it might make it much more complex to maintain quality as a whole. For example, in Plasma we've had problems already because of the fact that we need to make sure different versions are compatible with each other. Also we won't be able to run our CI with every single combination, which also makes it slightly more complex. I understand why it may seem more complex, but I don't think it actually is. Whether we choose to track development process using a version number, or whether we choose to track time using that number, what happens in the code remains the same. The same goes for dependencies; We will always have to rely on newer features sometimes, and thus bump dependencies. which means it will in practice be always broken. Real world example: kwin.git/CMakeLists.txt set(KF5_MIN_VERSION 5.8.0) yeah sure, that looks a lot like someone forgot to update the dependency. I don't think the claim that because it can break, it's in practice always broken, holds. Of course it's possible that it breaks, and typically this results in someone complaining (ideally CI), which gives you as developer two options: * Don't use the feature because you didn't mean to bump the dependency. * Bump the dependency This is IMO valuable feedback. We basically require that developers check for each change: * which version of a given framework the API call was introduced * whether that's currently the required dep * otherwise increase the dep Yes, that is something necessary that everyone does for all other libraries as well. When your required library is not available on the target platform you won't have any fun developing for it. If for kwin you always rely on the latest feature from library X, then you're certainly entitled to bump that dependency for every release. Keeping dependencies low is mostly interesting for lower-level libraries that strife for portability and thus try to keep dependencies to a minimum. I'm not interested at all forcing that focus on anyone, just in enabling those who have it anyways. That's not going to work. We either have CI for that (which we don't and don't have the resources for) or we go the secure rout: bump all at once. Bumping cmake dependency version does not give any security IMO. Frameworks can continue to provide snapshots of the latest and greatest that have been QA'd etc. I see absolutely no need to give any guarantees beyond that, and if for kolab we use some exotic combination of versions on some obscure platform, then it is indeed our responsibility to ensure that this actually works by i.e. running appropriate CI. As much as I think that in theory you are right and a more fine granulated dependency checking would be better, I doubt that this can work in practice without proper CI (and of course the CI can only check build deps, not runtime behavior changes (e.g. KWin needs a bugfix from KWindowSystem 5.10)). Unittests do check runtime behavior, and while I appreciate that our world is not perfect and not everything is completely covered, just bumping versions doesn't solve the problem. Btw. I'm not even suggesting changing the combined software versions: libkolab depends on Qt 4.6.2 since forever, but I'm certainly not developing using that ancient version. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf chrig...@fastmail.fm wrote: Hi Christian, I understand your needs, I've seen similar complaints before. Letting frameworks depend on different versions could make sense, but I also fear it might make it much more complex to maintain quality as a whole. For example, in Plasma we've had problems already because of the fact that we need to make sure different versions are compatible with each other. Also we won't be able to run our CI with every single combination, which also makes it slightly more complex. I understand why it may seem more complex, but I don't think it actually is. Whether we choose to track development process using a version number, or whether we choose to track time using that number, what happens in the code remains the same. The same goes for dependencies; We will always have to rely on newer features sometimes, and thus bump dependencies. It's just, if we don't reflect those changes using version numbers, because all the numbers are always the latest and greatest, then we don't know in what state we are (which library depends on which version of another library etc.). I don't think it eliminates any actual problems though (we're only messing with version numbers after all). As for combinations, I think it's only normal for upstream to only maintain the latest and greatest, and do QA for that only. The regular snapshots that are currently happening can and should continue to happen, and that's a set that can then be QA'd etc. If we did just that, we'd have more meaningful version numbers, and IMO really wouldn't loose anything. I of course would then hope to do some release management on the libraries where it is important enough, and where we can afford to spend the time for that. On the example of kimap that would mean that master would be in an always releasable state, so the frameworks release-process can take snapshots whenever it likes, and other libraries can depend on whatever version is currently in master (knowing that the dependency will be released together with the rest of the frameworks on the next release date). If I don't manage to get the planned features in for the next release, I would simply not merge to master, and the framework would stay the same. If anything that would reduce the combinations that have to be tested, because some will just stay the same. Also we're doing it similarly to how Qt does it anyway. Is it also a problem to bump all Qt frameworks when you need another one? Is there something that comes easier there that we don't offer? Or is it that we just have too many frameworks? Hmm... Didn't think about that a lot so far.I think in general it would be valuable for Qt too treat individual libraries separately. I think it's less of a problem in that case, because the possibility that we have to update Qt is much lower (I'd typically rather workaround a problem instead of distributing a patched Qt version, which I guess is a symptom of the same problem). So Qt is largely not update-able in my world, which is why I also currently have to maintain compatibility back to Qt 4.6.2. This of course comes at the cost of maintaining workarounds, and at an opportunity cost that I end up working workarounds instead of the core product (Qt). I don't think we have too many frameworks, what's important for us is to keep the dependencies to a minimum, and to keep the necessary changes is those dependencies to a minimum. If we find a bug in version 1.6.3 of library X (and it really shouldn't matter whether it's a KDE framework or some other library), then we patch it if feasible and distribute a fix. If we did our job with that fix we're not breaking any other uses of that library on the same system an thus we're good. If we rely on a new feature of the same library that is in version 1.9, and we see that all dependencies are still the same, then we can update to this new version with relatively great confidence and ease, because we're not touching a whole lot. If updating to 1.9 pulls in a whole tree of required updates it's just unlikely to happen, and I end up implementing some obscure workaround for that. So I don't think Qt offers anything that helps the problem, it's just that we interact less with it, and often we just use what's there since forever anyways and thus we don't care a whole lot about versions. Cheer, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Versioning of Frameworks
On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf chrig...@fastmail.fm wrote: Hi Christian, I understand your needs, I've seen similar complaints before. Letting frameworks depend on different versions could make sense, but I also fear it might make it much more complex to maintain quality as a whole. For example, in Plasma we've had problems already because of the fact that we need to make sure different versions are compatible with each other. Also we won't be able to run our CI with every single combination, which also makes it slightly more complex. I understand why it may seem more complex, but I don't think it actually is. Whether we choose to track development process using a version number, or whether we choose to track time using that number, what happens in the code remains the same. The same goes for dependencies; We will always have to rely on newer features sometimes, and thus bump dependencies. which means it will in practice be always broken. Real world example: kwin.git/CMakeLists.txt set(KF5_MIN_VERSION 5.8.0) yeah sure, that looks a lot like someone forgot to update the dependency. We basically require that developers check for each change: * which version of a given framework the API call was introduced * whether that's currently the required dep * otherwise increase the dep That's not going to work. We either have CI for that (which we don't and don't have the resources for) or we go the secure rout: bump all at once. As much as I think that in theory you are right and a more fine granulated dependency checking would be better, I doubt that this can work in practice without proper CI (and of course the CI can only check build deps, not runtime behavior changes (e.g. KWin needs a bugfix from KWindowSystem 5.10)). Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Wed, Apr 29, 2015, at 01:29 PM, Martin Gräßlin wrote: On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote: On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf I don't think the claim that because it can break, it's in practice always broken, holds. Of course it's possible that it breaks, and typically this results in someone complaining (ideally CI), which gives you as developer two options: * Don't use the feature because you didn't mean to bump the dependency. * Bump the dependency This is IMO valuable feedback. out from my experience: we don't get this feedback. I do get this feed back for i.e. libkolab where portability is a necessity. It makes complete sense that it isn't really something you'd i.e. require for kwin, and thus you can also carry on bumping requirements there if that works better for you. These are unlikely combinations which hardly anyone uses. Distros give you a combined latest release. This will be the one in a million use-case like yours. So the frameworks you use will continue to work, because you will notice. What about the others? We have currently 60 frameworks, with each release introducing more. Do the math of the possible combinations. There is no math involved, because as I said, complexity for upstream does not increase. You don't have to maintain any other combinations that what you already do. Just because the cmake versions aren't automatically bumped doesn't mean you suddenly have to test every conceivable combination of versions. Just look at Qt: Qt currently depends on glib2 2.8.3 (http://doc.qt.io/qt-5/linux-requirements.html), and on my fedora system I have 2.38.2. No-one expects Qt to be testing qt with every combination of all libraries existing, just because Qt doesn't depend on glib 2.38.2. I think exactly the same applies to frameworks. We basically require that developers check for each change: * which version of a given framework the API call was introduced * whether that's currently the required dep * otherwise increase the dep Yes, that is something necessary that everyone does for all other libraries as well. When your required library is not available on the target platform you won't have any fun developing for it. If for kwin you always rely on the latest feature from library X, then you're certainly entitled to bump that dependency for every release. I can give you several examples where KWin increased the required dependency without increasing the required version and again with nobody noticing (I just checked the CMakeLists.txt - for dependencies like KDecoration2 or KWayland we do not even specify a required version). How come this is not caught? Because nobody uses these outdated versions. We depend on something distros already provide (heck even I use distro packages), thus the fact that we start to depend on later versions won't be caught by distros compiling, neither by users compiling. My reality shows me that this is not working and I doubt that KWin is full of incompetent developers who cannot get the dependencies right. I don't think you're incompetent developers at all. As you said, noone is using older versions, and thus you don't notice when it breaks, fair enough. From that you can either come to the conclusion that you want to keep dependencies on a minimum nevertheless, and thus employ CI, or that you don't care and thus always depend on the latest and greatest. I assume for you it's the latter and that completely fine. Bumping cmake dependency version does not give any security IMO. Frameworks can continue to provide snapshots of the latest and greatest that have been QA'd etc. I see absolutely no need to give any guarantees beyond that, and if for kolab we use some exotic combination of versions on some obscure platform, then it is indeed our responsibility to ensure that this actually works by i.e. running appropriate CI. really? I would be pissed as a user if it promises a dependency which it doesn't work with. That's kind of an external contract in my point of view. Well, we do currently give BIC guarantees, which means unless a new feature is used this *has* to work anyways. We already promise that if I use the featureset of library version $X it will work exactly the same in version $X+n (apart from major version bumps). If we don't bump the dependency and use a new feature... well, that's just a bug, and bugs happen. You can assume that I will setup some CI to help me ensure it keeps building with the platforms I'm interested in, but that's then my problem for where I choose to do this work. I'm not asking everyone to keep dependencies on a minimum for all available libraries, I'd just
Re: Re: Versioning of Frameworks
On Wednesday 29 April 2015 12:19:18 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 11:03 AM, Martin Gräßlin wrote: On Wednesday 29 April 2015 09:35:12 Christian Mollekopf wrote: On Wed, Apr 29, 2015, at 12:11 AM, Aleix Pol wrote: On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf chrig...@fastmail.fm wrote: Hi Christian, I understand your needs, I've seen similar complaints before. Letting frameworks depend on different versions could make sense, but I also fear it might make it much more complex to maintain quality as a whole. For example, in Plasma we've had problems already because of the fact that we need to make sure different versions are compatible with each other. Also we won't be able to run our CI with every single combination, which also makes it slightly more complex. I understand why it may seem more complex, but I don't think it actually is. Whether we choose to track development process using a version number, or whether we choose to track time using that number, what happens in the code remains the same. The same goes for dependencies; We will always have to rely on newer features sometimes, and thus bump dependencies. which means it will in practice be always broken. Real world example: kwin.git/CMakeLists.txt set(KF5_MIN_VERSION 5.8.0) yeah sure, that looks a lot like someone forgot to update the dependency. I don't think the claim that because it can break, it's in practice always broken, holds. Of course it's possible that it breaks, and typically this results in someone complaining (ideally CI), which gives you as developer two options: * Don't use the feature because you didn't mean to bump the dependency. * Bump the dependency This is IMO valuable feedback. out from my experience: we don't get this feedback. These are unlikely combinations which hardly anyone uses. Distros give you a combined latest release. This will be the one in a million use-case like yours. So the frameworks you use will continue to work, because you will notice. What about the others? We have currently 60 frameworks, with each release introducing more. Do the math of the possible combinations. We basically require that developers check for each change: * which version of a given framework the API call was introduced * whether that's currently the required dep * otherwise increase the dep Yes, that is something necessary that everyone does for all other libraries as well. When your required library is not available on the target platform you won't have any fun developing for it. If for kwin you always rely on the latest feature from library X, then you're certainly entitled to bump that dependency for every release. I can give you several examples where KWin increased the required dependency without increasing the required version and again with nobody noticing (I just checked the CMakeLists.txt - for dependencies like KDecoration2 or KWayland we do not even specify a required version). How come this is not caught? Because nobody uses these outdated versions. We depend on something distros already provide (heck even I use distro packages), thus the fact that we start to depend on later versions won't be caught by distros compiling, neither by users compiling. My reality shows me that this is not working and I doubt that KWin is full of incompetent developers who cannot get the dependencies right. Keeping dependencies low is mostly interesting for lower-level libraries that strife for portability and thus try to keep dependencies to a minimum. I'm not interested at all forcing that focus on anyone, just in enabling those who have it anyways. That's not going to work. We either have CI for that (which we don't and don't have the resources for) or we go the secure rout: bump all at once. Bumping cmake dependency version does not give any security IMO. Frameworks can continue to provide snapshots of the latest and greatest that have been QA'd etc. I see absolutely no need to give any guarantees beyond that, and if for kolab we use some exotic combination of versions on some obscure platform, then it is indeed our responsibility to ensure that this actually works by i.e. running appropriate CI. really? I would be pissed as a user if it promises a dependency which it doesn't work with. That's kind of an external contract in my point of view. As much as I think that in theory you are right and a more fine granulated dependency checking would be better, I doubt that this can work in practice without proper CI (and of course the CI can only check build deps, not runtime behavior changes (e.g. KWin needs a bugfix from KWindowSystem 5.10)). Unittests do check runtime behavior, and while I appreciate that our world is not perfect and not everything is completely covered, just bumping versions doesn't solve the
Re: Versioning of Frameworks
On Tuesday, April 28, 2015 12:17:00 Christian Mollekopf wrote: Hey, For the Kolab Groupware Server we use some KDE libraries on the server. Servers being what they are, the libraries we require are often not available by default because the systems are too old, and we end-up backporting what we need. To make this feasible in pre-framework times I had to create a copy-paste monster that contained all the libraries we required, and stripped everything we didn't, to keep the dependency tree at a manageable level (so we don't end up updating some 100+ packages). Now with frameworks, we are finally in the position to get rid of this, but as far as I understand, at least some frameworks are in version-lock with each other, which seems to defeat at least parts of the benefits. 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. This comes at significant cost if we have to backport all packages. Ideally framework-libraries should IMO be versioned as any other library that I know of, which is bumping numbers as changes happen. 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. My favorite versioning scheme is the one explained here [0] (major.minor.teeny with minor for features, and teeny for bugfixes), which is almost what we do, since we already use the major version-number to indicate API incompatibilities. But currently the versions are just used to time-stamp the releases. 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. Just to give my +1 I also think this is a big issue. Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a too recent version of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick dirty way) I also think this somehow defeats the purpose of the splitting we've done when you still have to make sure versions of the individual frameworks have to be identical... Greets * 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. I assume the current versioning is happening so noone has to maintain the individual version-numbers, so the question becomes whether it would break anything moving partially away from that. 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. If it goes well with kimap, I'd then just approach the individual maintainers. It's of course quite possible that I don't understand the requirements of others, so I'm interested to hear about that as well =) Cheers, Christian [0] http://semver.org/ Our dependency tree is roughly (it's currently larger, but we should be able to get it down to that): * PIM (not yet part of frameworks) ** KCalendarCore ** KCalendarUtils ** KMIME ** KIMAP ** KContacts * Current Frameworks ** ECM ** KCoreAddons ** KConfig ** KI18n ** KDELibs4Support ** KCodecs ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Versioning of Frameworks
On Wednesday 29 April 2015 15:00:32 Christian Mollekopf wrote: You don't have to maintain any other combinations that what you already do. Just because the cmake versions aren't automatically bumped doesn't mean you suddenly have to test every conceivable combination of versions. How can the developer write in KIO's CMakeLists.txt this depends on KXmlGui 5.5 and KCoreAddons 5.2 without testing that it actually works with these versions? Or the other way around -- if it is at one point indeed working with these versions, what will happen is that someone will use a new feature from an underlying framework at some point, and forget to upgrade the required version. This will happen many times per month, not just once a year, I know this for sure. See the number of times where someone commits Qt-5.4-only code right now in frameworks that are supposed to work with Qt 5.2, but they don't realize when writing QSignalSpy(obj, Class::member) that this syntax wasn't available in Qt 5.2. It's already a fight to get this right with the *one* Qt version number, I can't even imagine how tricky this would become with 62 * 5 = 310 version numbers to keep right (62 frameworks each depending on an average of 5 other frameworks - I made up that number, feel free to calculate it more precisely). Anyhow, there is little point in arguing for ever about this. As long as I'm doing the Frameworks releases, they will have the same version numbers and they will require the same version number from their dependent frameworks. Sorry to put it so bluntly, but there is no other solution that is actually manageable. Releasing framework is already not a fun task, I will gladly give it over to someone else if they think they can do a better job, but OTOH I think the current release process works quite well (changelog aside), so I would not advocate this (changing it by having someone else do it differently). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote: Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a too recent version of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick dirty way) If this contributor was trying to fix a bug in a Qt module, he would experience the exact same thing. QtAnything 5.5 cannot be compiled with QtBase 5.2. I also think this somehow defeats the purpose of the splitting we've done when you still have to make sure versions of the individual frameworks have to be identical... So do you also think that Qt failed with the module split ? I disagree. The point (both for Qt and for Frameworks) is that any app can decide to use only what they need. Having to use up-to-date enough versions of the dependent modules does not defeat that purpose. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
Christian, David isn't the only one with these thoughts. I agree with everything he said, and was thinking about the dependency zoo also, but couldn't form the words until I read what he wrote. That's exactly what I was thinking. It would be like the old rpm dependency hell from early linux days all over again, but within our community only. BR, Jeremy On Wed, Apr 29, 2015 at 12:34 PM, David Faure fa...@kde.org 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
Re: Versioning of Frameworks
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
Re: Versioning of Frameworks
On Tue, Apr 28, 2015 at 12:17 PM, Christian Mollekopf chrig...@fastmail.fm wrote: Hey, For the Kolab Groupware Server we use some KDE libraries on the server. Servers being what they are, the libraries we require are often not available by default because the systems are too old, and we end-up backporting what we need. To make this feasible in pre-framework times I had to create a copy-paste monster that contained all the libraries we required, and stripped everything we didn't, to keep the dependency tree at a manageable level (so we don't end up updating some 100+ packages). Now with frameworks, we are finally in the position to get rid of this, but as far as I understand, at least some frameworks are in version-lock with each other, which seems to defeat at least parts of the benefits. 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. This comes at significant cost if we have to backport all packages. Ideally framework-libraries should IMO be versioned as any other library that I know of, which is bumping numbers as changes happen. 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. My favorite versioning scheme is the one explained here [0] (major.minor.teeny with minor for features, and teeny for bugfixes), which is almost what we do, since we already use the major version-number to indicate API incompatibilities. But currently the versions are just used to time-stamp the releases. 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. * 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. I assume the current versioning is happening so noone has to maintain the individual version-numbers, so the question becomes whether it would break anything moving partially away from that. 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. If it goes well with kimap, I'd then just approach the individual maintainers. It's of course quite possible that I don't understand the requirements of others, so I'm interested to hear about that as well =) Cheers, Christian [0] http://semver.org/ Our dependency tree is roughly (it's currently larger, but we should be able to get it down to that): * PIM (not yet part of frameworks) ** KCalendarCore ** KCalendarUtils ** KMIME ** KIMAP ** KContacts * Current Frameworks ** ECM ** KCoreAddons ** KConfig ** KI18n ** KDELibs4Support ** KCodecs ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Christian, I understand your needs, I've seen similar complaints before. Letting frameworks depend on different versions could make sense, but I also fear it might make it much more complex to maintain quality as a whole. For example, in Plasma we've had problems already because of the fact that we need to make sure different versions are compatible with each other. Also we won't be able to run our CI with every single combination, which also makes it slightly more complex. Also we're doing it similarly to how Qt does it anyway. Is it also a problem to bump all Qt frameworks when you need another one? Is there something that comes easier there that we don't offer? Or is it that we just have too many frameworks? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
