Versioning of Frameworks

[Christian Mollekopf]

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.

Cheers,
Christian