Versioning of Frameworks

[Christian Mollekopf]

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