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
