Versioning of Frameworks

[Martin Gräßlin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150505/cadd19f5/attachment.sig>