Versioning of Frameworks

[Christian Mollekopf]

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