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
