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